Worker Threads: Created by model or by controller?

Question

Sometimes models needs to access blocking devices, like network cards, databases, files, and so on. This should be done by worker threads or services. But who is in charge of that? The controller or the model itself? I tend to say it is the model, as only the model knows about the fact that it accesses a blocking object. On the other hand, it is said that a model should be a POJO, so it would be the controller's job.
Is there a best practice or general design rule?

Answer 1

It's impossible to make a general recommendations, but I'd say in many cases the answer to this question is really that the worker threads are created by neither a model or controller.  Threads often need to be associated with processes and tasks which is independent of models and controllers.  Instead you can use dependency injection to inject references into controllers to a common object instances which control isolated threading logic and implementation and encapsulate it to server a given responsibility (such as blocking server communication), with the entity providing this functionality also providing event driven callbacks to the models and controllers, so that they can get notified of changes for tasks spawned based upon their requests.  For example, if you look at the Java JEE model, entity classes and controllers in that model usually never explicitly create or reference threads (that portion of JEE really a pretty general programming mechanism and is also applicable to client code in JavaFX).
MVC isn't a panacea solution to everything.  In fact it tends to be overly quoted and widely misunderstood and what it actually is is open to different interpretation by different readers.  There is a great discussion of MVC by Martin Fowler.  Everybody claims to do MVC, and they are all doing it, they are just doing it in a different way, which is fine, but it means that it is not a very good reference in trying to communicate solutions to issues such as architecting a multi-threaded application.
What I would recommend instead of analyzing your entire application from an MVC viewpoint, is to use CRC modeling on it (class/responsibilities/collaborations), you can google it to see how it works if you don't already know.  That way you are thinking about how to architect and build a solution to your application domain issues rather than trying to shoehorn solutions into a certain framework.  Sure MVC is a great thing and is appropriate for many things, just make sure you really want to think from that viewpoint for a particular piece of the solution you are building.
With threading, you generally want to write as little concurrent code as possible.  You also want this code compartmentalized, so you only need to study the concurrent code in one place (hopefully a single class or at most a single package).  You also don't want the knowledge and use of the threads to leak.  For example, ensure that almost all the code you write is only accessing a single thread so that you don't have to worry about concurrency related bugs and reasoning about concurrency in most of your code.  This is the way the JavaFX system works.  It has multiple threads internally for application processing and rendering, but from a user point of view, all the user application code just runs on a single JavaFX application thread.  This makes the user code less error prone and easier to reason about and also simplifies the library API and usage greatly.
So let's say you have a server communication API which makes use of a multithreaded client pool of server connections such as apache HTTP components.  Create a single class, e.g. Communicator with methods ResponseMessage send(Location destination, RequestMessage requestMessage) and void sendAsync(Location destination, RequestMessage requestMessage, Callback<ResponseMessage,Void> callback).  The async version, can make use of Platform.runLater, to ensure your callback is invoked on the JavaFX application thread - then your calling JavaFX application code never needs to worry about the internal threading implementation of the communicator, it just reacts to an event driven callback (the same way something like the snapshot API works).  If you need more fine grained feedback and control over the async task from your application, than rather than having a simple callback, you can return a Worker/Task which can be monitored for progress within your JavaFX application, see for instance the LoadWorker in WebEngine.  If your communication implementation is actually reasonably involved and can't be implemented in a single class, that is OK, just make Communicator a facade and use multiple classes in the internal communicator package implementation, but don't use any of that implementation outside of the communicator package.  You can use a dependency injection framework such as afterburner to inject a reference to a communicator into your FXML controllers.