PHP MVC Best Practices/"Rules" for Success [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I'm sure that someone already posted this question; however, I would like to get all kind of recommendations for MVC on PHP. I know there are many experts out there willing to share th开发者_Python百科eir knowledge with people who has doubts about their coding best practices.

• How should you organize your Controller?
• How should you organize your Model?
• Should Controller call one Model Method and the Model call submethods or should controller call all Model Submethods?
• etc.

Hope this helps someone out there (because it'll help me for sure).

---

MVC is the most misunderstood design pattern. There is by definition one model.

When an urban planner proposes a project, he designs one model for it. The separate entities that the model might be comprised of: buildings, streets, parks, are typically not represented by separate models: they are all facets of the single model.

So in MVC, the model can be comprised of different entities, and that is probably the best word for it: entity, as in an entity represented by a database table. The model in MVC might even be something more abstract than is actually represented in code, but rather a conceptual umbrella for all of the data that the application might need to act upon.

Considering this, if these entities have their own methods, notably methods that might correspond to the facets of CRUD (create, read, update, delete), they should not be exposed directly to the controller, it is too low a level of abstraction. These building blocks should be built up into a coarser grained interface, for instance you might delete a record but then return the list of records after the deletion. The controller just needs access to a coarser grained method that performs all of the above.

Furthermore, to expose the methods of the entities directly to the controller, could cause the controllers to have to be rewritten, along with the entity classes, if there is a change for instance as to what ORM (object relational mapping) system is being used. The intermediate layer I'm suggesting also is a good place for exception handling, logging and any other such administrivia that needs tending to.

The suggested layer of methods at a higher level of abstraction is sometimes referred to as the business delegate, or a "facade", but this is what I actually consider the model. Hope this isn't too theoretical, and is helpful to the OP or other readers.

---

I find the blog relevant to your question.

https://r.je/

Tom Butler the blog author points out the way most MVC frameworks allow model-view interaction is not correct and tries to explain In MVC the view should access the model directly using a few examples.

He has a valid point, However coming from the Rails background I found it difficult to gulp the idea of view accessing the model directly.

---

For php, I like to use the CodeIgniter framework. It lays the ground work for the MVC set up. The controllers are held in "/controllers" and models are in "/models"

I believe that a controller should call the model and the model should encapsulate as much as it can, using submethods if needed. This makes your code much more adaptive and flexible. Example, today your model is reading from a local database, tomorrow you could be reading from a REST service. The model should return data to the controller and the controller should be naive to what is going on inside of the the model.

---

I'm not sure what you mean by "organize".

The controller calls on whatever model[s] it needs in order to get the information to pass to the view[s]. It (the controller) can make multiple calls to the model for different pieces of information.

Try reading this: http://www.phpwact.org/pattern/model_view_controller

---

The secrets of the MVC is that the "M" MODEL should be creates and designed as a VIEWMODEL, not a simple Model.

Let's say that we have the next example: We have a form when the insert a entity called Customer :

Customer

• IdCustomer
• Name
• SurName
• Country.

The MVC rule says that we should sends the Customer MODEL to the View. However, let's say that the Country field is filled with a combobox. Then, we should send a list of country to the VIEW.

So, we will have the next VIEWMODEL

CustomerViewModel

• Customer
  • IdCustomer
  • Name
  • SurName
  • Country.
• CountryList

Also, usually a form is not as simple as field and nothing more, it has buttons, label/messagebox and such. It should be modeled in the VIEWMODEL