October 16th, 2012, 11:43 AM
MVC - What Goes Where?
I'm a little confused as I embark on building a new webapp using an MVC framework.
My OU course taught me that the model has business logic and the controler is a 'has a' relationship with the models it uses, as usually you declare a variable as the model and then perform methods against the model to manipulate data / information.
However, looking at a few web MVC frameworks, they seem to consider the model as purely a DB table, so I assume the functionality and business logic goes in the controller.
So what do you beleive should go in the model vs controller, what ethos do you use to make the decision?
Your input is appreciated.
October 16th, 2012, 03:50 PM
Just my opinion based on the framework I use, the model portion of MVC is the logic portion of the page being requested and changes on each request. The controller portion happens on every page request before it selects the models to be used. This can be broken down in to multiple layers of controllers though.
For instance the main controller goes through all the sessions, authentication, database connection, etc. Then that controller finds what sub controller to use for the current page. So for example, you might have an Admin controller that for every page within Admin you need to gather some data about the current user viewing the Admin page, you set up toolbars and basically the skin of the Admin page.
Then the model comes in when the user selects the different features on the Admin page, like accounts, permissions, etc. So I view it as the model changes on each page request whereas the controller is needed on each page request.
I actually separate out my files as
Where Brains are where the specific logic happens for the current page request.
This is purely just my opinion though but it seems to make sense and work for me.
October 16th, 2012, 07:00 PM
Whether your models should contain business logic or not is debatable, but your controllers should contain as little business logic as possible. The reason is pretty straight forward: it doesn't make sense for one controller to execute code from a sibling controller. In fact, most frameworks make it really difficult to actually do that. Thus, anything that you want to use on more than one page shouldn't go into a controller.
Where that type of code actually goes though depends a lot on the specific framework. Some put it into the model, some put it in other places (ie not in M, V or C).
October 16th, 2012, 08:33 PM
If this is hi-jacking the users thread I apologize, but I think it goes right along with it. E-Oreo can you give a real world example of MVC? From what I gather you basically say that there are some elements within page creation that do not fit within the framework. I was always under the impression that the whole process was included in MVC, which is why I call my sub levels controllers, which you clearly mention that they are not.
So for instance what is part of the MVC in this process?
User clicks on a page and all page requests go through index.php
All the sessions, authentication, configuration, etc is done in this process
If everything checks out the controller.php file is called which breaks apart the url to get the designated sub controller
Here is the sub controller (ex. admin). This does another round of authentication, builds the toolbars or navigation bars and any other common functionality for the admin module.
Then reading from this controller you have the logic portion which would be like accounts or permissions.
Throughout the process the variables are created, the appropriate templates are chosen and at the end the templates are processed.
Maybe I'm just confusing the parts but what in this process would be part of MVC and what would not?
October 16th, 2012, 09:11 PM
I wasn't disagreeing with you at all, multi-layer controllers like you describe are very common and completely logical for an object oriented framework. However, the actual business logic, unless it deals directly with input or output, shouldn't usually live in the controller. Although most pages can be organized into a strict hierarchy, not all of the functionality fits into a single hierarchy well.
For example, if you have a method that computes the tax rate for an order, it doesn't make much sense to put that into a controller since you might need it on many different pages (a user facing order history page, an admin facing view order page, an API call to the application, etc.) that don't fit under a common hierarchy. So your options are either to put a huge amount of functionality into your base controller, or else put it somewhere else that can be shared between controllers from different hierarchies.
Things like checking authentication and permissions are definitely things you would want to kick off from your controllers, but may not be things you want to be doing from the controller code itself. Things like session initialization and configuration loading are normally considered to be part of the bootstrapping process, which depending on what framework and terminology you use could be considered part of the controller or something outside of MVC.
October 17th, 2012, 12:20 PM
well I was trying to use Catalyst and it seems to have a master framework plugin mechanism for authentication , session etc.
Many wepapp frameworks that use ORM seem to have the Model as simple a DB table layer and expect you to code all logic in the controller. here is an example for Mojolicious http://mojolicio.us/perldoc/Mojolicious/Guides/Growing simply scroll down to the MVC heading and the diagram which seems to shrink the model and expand the controller.
I think all this will be pretty mute if I can't get Catalyst to run on IIS7, it won't recognise the paths for controller/method mapping and all I ever get is the root index method.
I've exhausted all avenues , searched Google for an entire day, there is no support for Catalyst , no forums, no community, nor any tutorials for IIS7 that work, nothing!
I've now signed up to their mailing list in a last desperate attempt to get some answers so I can start actually developing, but if that goes no-where then I give up and say screw you MVC!