PHP MVC & SQL minus model
I read several articles about MVC and had a few questions that I was hoping someone could help me with the answer.
First, if a MODEL is a representation of data and a means for manipulating that data, then a data access object (DAO) with a certain level of abstraction using a common interface should be sufficient for most tasks shouldn't it?
To go into more detail on this, let's say most of my development is done using MySQL as the main storage engine for my data, if I avoid vendor specific functions (i.e. UNIX_TIMESTAMP) - when constructing my SQL statements and used an abstract DB object that has a common interface moving between MySQL and maybe PostgreSQL, or MySQL and SQLite should be a simple process.
Here, what I get when doing any task is handled by one CONTROLLER - (i.e. UserRegistration), and rather, to create a MODEL for that task, I can get an instance of the db object - (i.e. DB :: getInstance ()) and then make the necessary db calls to INSERT the new user. Why, with such a simple task, will I create a new MODEL ?
Some examples I've seen create a MODEL and inside that MODEL there is a SELECT statement that selects x number of orders from the orders table and returns an array. Why do this if in CONTROLLER you create another loop to iterate over this array and assign it to VIEW ; ex. 1
ex. 1:
foreach ($list as $order) { $this->view->set('order', $order); }
I guess it would be possible to change the return, so something like this might be possible; ex. 2.
ex. 2:
while ($order = $this->model->getOrders(10)) { $this->view->set('order', $order); }
I suppose my argument is why create a model when you can just make the necessary db calls from your CONTROLLER , assuming you are using a generic interface DB object to access your data, as I suspect most web sites use. Yes, I don't expect this to be practical for the entire task, but then again, when most of what is being done is simple enough not to necessarily warrant a separate MODEL .
Currently the user makes a request "www.mysite.com/Controller/action/args1/args2", the front controller (I call it a router) goes to the controller (class) and inside that controller a a specific action (method) is called and from there VIEW is created and created .
source to share
So I think you're wondering if the added model-level complexity on top of the database access object is the way you want it. In my experience, simplicity trumps any other problem, so I would suggest that if you see a clear situation where it is easier to simply dispense with the model and have access to the data in the controller equivalent, then you should go with that.
However, there are still other potential benefits to MVC separation:
- There is no SQL in the controller at all: maybe you decided to collect your data from a source other than the database (array in session?) Mock object to test the file? just something else) or change database schemas and you have to look for all the places your code needs to change, you can only view the models.
- Sharing skillsets: Someone on your team may be good at tricky SQL queries, but not very php-savvy. Then the more separated the code, the more people can play to their strengths (even more so when it comes to the html / css / javascript side).
- Conceptual object representing a block of data: as Stephen said, the difference is in the benefits you get from database agnostic (so you can switch between mysql and postgresql if needed) and be schema agnostic (so you have an object full data that mixes well even if it comes from different relational tables). Once you have a model that is a good block of data, you should be able to reuse that model in multiple places (for example, a user model can be used when logging in and when displaying a list of personnel).
I certainly find the MVC task separation ideals to be very useful. But over time, I've come to the conclusion that alternative styles, such as keeping an MVC-like separation with a functional programming style, may be easier to deal with php than a full blown OOP MVC system.
source to share
I found this great article that covered most of my questions. In case someone had similar questions or is interested in reading this article. You can find it here http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html .
source to share
The idea behind MVC is to have a clean separation between your logic. So your view is your output, and your controller is the way to interact with your models and use your models to get the data you need to provide the views you need. But all the work to get the data will follow your model.
If you think of your user model as an actual one and not a piece of data. If you want to know that a person's name is easier to call the central office on the phone (database) and ask for a name, or just ask the person "what is your name?" This is one of the ideas behind the model. In its most simplistic form, you can view your models as real living things, and the methods you attach to them allow your controllers to ask these living things a series of questions (IE - can you view this page?) Are you signed in? image you published? When were you last modified?). Your controller should be dumb and your model should be smart.
Another idea is to keep your SQL running in one central location, in this case your models. So that you don't have erroneous SQL floating around your controllers and (worst case scenario) your views.
source to share