Yikes. No wonder people get confused about MVC with all this conflicting (and erroneous) information.
MVC has three distinct parts … you list two kinds of Controllers, a template and no Model!!! I don’t know what “Master Front Controller” and “Business Controller” are? Typically in PHP you will have a Front Controller that dispatches an Action Controller. Technically the combination of both is the Controller in MVC. In practice, the Action Controller is often referred to as the “Controller” since those are the things you work with most.
Business logic is the whole point of the Model! The Model is what contains all the stuff in the Domain that makes the application what it is. Definitely push as much domain logic into the Model as you can and keep the Controllers minimal.
If the Model is not supposed to “access” or be “coupled” to the database … then what is? The View? The Controller? These are the kind of statements that confuse people about MVC. The Model is certainly where access to persistent data should occur. In PHP it can do that through a DAO or directly. It is up to you whether you want to add a Datasource layer below your Model layer. That is irrelevant to MVC which only says the Model is not in the Presentation layer with the View and Controller. And that separation is the important one in MVC. As to whether the Controller or View should “access” the Model – it is up to you. Both Controller and View are in the Presentation layer and can have a dependency on the Model.
sunwukung, listen to what TomB is saying. He is leading you in the right direction.
Honestly though it would be very fascinating if we all could seat in 1 room w/ big white board. I think what’s going on here is that people read the post word by word. Like the saying, 1 picture = 1000 words. For the above posts. Of course there is a model!!! Why would I mention modelDAO if it’s not involved in the process. Model is what gets passed to the controller. That’s like saying I will never get dynamic content from the server.
I’ve only skimmed this thread and maybe this weekend I’ll read it fully, but here are some points about mvc…
Domain Model != MVC Model
Sure a Domain Model object could be used by a view but not always and in some cases would be completely inappropriate. I prefer making specific model classes and instances for specific views. In Java with Spring MVC these are called form backing objects and they should then either be the ‘model’ or contain the other model classes for the specific view. For instance when displaying an html table with information from many different Domain Objects, it would be more appropriate to produce a Table Model that has the correct information for the table and then pass that Table Model to a Table Component to render the Table Model.
Please look at Java’s implementation of Swing for a very nice example of MVC.
Validation.
I would recommend having validation external of your domain objects. Different controllers will/can require different validation.
Break validators down into separate classes that only validate one rule. Does the attribute have a value? Is the attribute a number? Is the attribute already in the database? It is acceptable to have database access in a validator, but perform those checks last.
Then build a controllers validator from chaining multiple smaller validators together. Performing required checks first and returning any errors, then data validation and returning any errors, and then finally your validators that require data access.
Domain Models and Persistence
I really recommend against having database access or logic in your Domain Model. Your Domain Model is just that, the definition of your domain. It is that simple. I’ve hardly ever heard of anyone saying that our customer access the database directly to get their data in any requirements meeting I’ve been in. That being said the Domain Objects in a way represent the problem and attempting to keep the code as cleans as possible to explain exactly what the problem is, is, important. Having persistence logic in your Domain Model will muddy the ability to see the problem.
HOWEVER, if you wish to implement lazy loading or some other type of database improvement consider proxying your classes with wrappers that will handle the database code for you. This of course implies that you’ve programmed using interfaces for your Domain Model classes. Luckily for us in the Java world we have Hibernate to take care of this problem.
Isn’t that pretty much what arborint said? Anyway, I wanted to quote it because not appreciating this distinction seems to be where people get confused with MVC.
However one thing that needs to be made clear here is: MVC doesn’t specify how your models (or controllers or views for that matter) work, only that they’re the part of the application that deal with the domain logic nor does it define how the model interacts with the database. Some ways are better than others, of course… but the implementation is nothing to do with MVC.
I don’t disagree with anything you said, but MVC architecture has no bearing on the merits of Data Mappers vs Active Record, where validation should be done or even OO vs procedural programming.
The problem I have is, getting caught up on these implementation details appears to be where people get confused because it makes MVC seem to be a bigger, more daunting and confusng topic than it really is and it detracts from the actual MVC related design decisions you need to make. Not that I’ve not wandered into implementation detail myself of course.
On reflection, it’s certainly preferable for aspects of your model to be directly accessed from the View. (When I say access, I mean read, not written). As TomB pointed out, passing specific model output variables into the view from the controller tightly couples those layers. This coupling will prevent “widgetizing” of your models/views.
In long term projects, adding new modules to an application requires integration of new features into an existing code base. The coupling of the model and controller will make it much harder to “drop” modules into place, without causing a ripple effect throughout your existing controller logic.
Well I had been parsing an INI file (directory protected by .htacces) previously inside of a Database Construct, I wanted to simplify it with this, I haven’t considered how these Constants are flawed, I just wanted an easy way to transfer Data from one spectrum to another. I guess I’ll have to rethink this
I don’t look at WordPress’ back-end I didn’t know they did that lol.
