(MVC) Controller in shared library?

Question

In MVC, do controllers belong with an application, or can they go into a shared library? For example:

//this is a shared library
LibShared

//these are two apps
appA ->LibShared
appB ->LibShared

Shouldn't each app implement its own MVC and use any shared libraries as perhaps part of the app's logical model or simply another library reference (utilities)?

Also, is there ever a situation in which an MVC Controller is stuck in a shared library? I thought Controllers needed specific views located in a specific app. Meaning, the Controller must go in that app?

Or can Controllers be generic (i.e. shared library)? Doesn't that mean they are no longer Controllers?

Answer 1

I suppose any code can go anywhere, what would drive us to put something in a shared library or keep it with the app?

I would consider two things:

1). What's the rate of change? When we change the app overall is this likely to change. 2). Could anything else need to use it? If so when I realease a new version would the other client immediately

Typically a controller would be strongly associated with the application and hence not of much interest to any other app, and it's probably fundamental to the app changing as the app changes. Hence packaging with the app makes sense.

Now if the conroller is somehow more generic, perhaps configuration driven then shared library makes sense.

Answer 2

Controllers does not necessarily needs to be even in the same operating system. You could have a view in Windows, a Controller in Unix and your Model in a Sparc. Remember MVC is just a pattern, a way you could do something which is more robust and easier to modify.

Your controller could be a shared library. Does your controller should be aware of your views? Not necessarily. That depends on how you handle the communication between modules. On a good MVC implementation, modules simply interchange messages or events. So, a View send an event to the Controller, the Controller decides what to do and send a message back. The response of the controller could be something like "Show Window X". Be advised that "Window X" could be interpret by the View module, if the View is an a Web module, then the View just put the proper aspx page. If you have another view who happens to be a web application the renders Form X.

Answer 3

At least in CakePHP and in the architecture that Mike McShaffry explains in his Game Coding Complete book the controller does belong to the application.

However, in both cases the architecture is such that the application inherits the basic functionality of a model, view, and a controller from the framework.

Eg.:

// "super" controller of all applications using this framework
class Controller
// uses basic libraries that allows the inheriting applications to work minimally

class AppController extends Controller
// mainly uses the parent class's methods but can also substitute to using
// additional libraries

By framework here I mean the system that encapsulates the use of libraries. In CakePHP this encapsulation in turn is done by using libraries in the respecting models, views, and controllers. So neither of those components is free from attachment to libraries.

In Mike McShaffry's architecture however, only the controllers and views use libraries. So the models are left uncoupled and are thus highly portable to different applications.

Answer 4

I would advise that you should only be separating out your controllers into their own module/package/library (herein referred to as modules) if you have a requirement to do so (i.e. immediate re-use). If no such requirement exists at present then I would defer the decision to when it is required, it sounds in your case you are about to unnecessarily over-engineer. It should in theory be possible to refactor later to a separate modules without much hindrance, however be careful regarding coupling, separating out to different modules doesn't reduce the coupling, look carefully at your dependencies at how much the controller is orientated to one style of view.