Good practices for PHP MVC

Question

I am deepening on the use of MVC using PHP, and after seeing some lessons and articles on the Internet I had some doubts about its use, since I found classes that present the same case differently. I know there is no perfect way, but I would like a clarification of what would be the best practice to adopt.

1°) The connection to the BD must be made through the controller, of model or some other configuration file ? - I found articles that were made in both.

2°) I have to create a model per table? - Let’s say I have Table 1 and Table 2, and I need a SQL relating the two, I have to have a model separate for each of them, or model of Table 1 I make an appointment with JOIN among them?

3°) I have a button on a view which returns a completed form for example, this "code" of the form (being it in HTML with BD data), is mounted on the model, controller or a view who has only this form?

4°) The folder with files CSS, JS and Imagens, has a specific location, type inside the app folder or folder View?

Answer 1

There is no such thing as good practice. There is right or wrong for every situation. Only qualified, more than quantified experience will provide the basis for achieving better.

Most of these classes out there are cake recipes that cloud people’s creativity, sell the idea that there’s only one right way to do it and often contain several mistakes.

1. Where the connection goes depends on the general architecture. Some will say it is in the model (in general, not within the data class), is not wrong, others will say that the model itself is only the data classes. Hardly the connection will be in the controller. I don’t see much sense in this, I can’t imagine a reason to do this. Whether to use a configuration file or not is a decision that has nothing to do with MVC.

2. Model is a layer, so in theory has one per application (it is not so simple, there may be models different). If you are talking about class, it can be one per database table. But it is not necessary to reproduce this. There may be model classes that are mounted by combined data from multiple tables or other information. It may not include any table. In the case of a join it can be interesting to have a class for this relationship.

3. The button generates an action for the controller. This controller will query the model, and at the end will generate a view. I do not know if I understood the doubt, but this is the MVC, it is essentially like this. It will not generate a vision when it must present anything. Only it will not consult the model if it does not need any data that is there (remembering that the model may have information beyond the database). Then it is assembled by the whole of the three things, each doing its part.

4. Organization of files you do the way you think best, MVC does not determine where to put. Patterns only determine what is relevant to solving a specific problem. You can change whatever you want in the pattern if you don’t change the result, if you don’t create a problem for the solution. Patterns can even be considered cake recipes, but as every recipe does not need to follow correctly. Of course if you do not know how to cook you will have more difficulty doing it right if you run away on the recipe. So my advice is to learn how to cook.

If you have more specific, more specific questions for your case, go ahead.

Answer 2

MVC is a design standard.

Design standards should be employed to solve a common and standardized "problem", allowing proven solutions and/or standardize architectures allowing a team to work homogeneously.

In this way, the MVC design standard was created to solve the logical organization problem of a project, using separation by responsibilities, thus the (M)model is responsible for manipulating data and/or the logical part of the application, the (V)is not responsible for applying all the information output logic - it can be a "screen" in HTML or the generation of XML or JSON responses; finally the (C)controller is responsible for orchestrating models and views by functionality, being the one who receives the action requests, identifies which models should process the data for a request and which views should return the request output/response.

It is also possible to apply other design standards together to solve various "problems" - Front Controller to centralize the request processing, allied to Dispatcher for identification and instantiation of the correct controller to handle a request; DAO/ORM/Active Records to handle persistent data manipulation; Layer Services for agnostic separation from application logic, etc.

Note therefore that there is a need to apply the concepts correctly.

Regarding your questions listed

1. the Model should handle data, this is the definition, do not think correct in the model, for example, make the connection with the bank, the ideal is to use dependency injection for this purpose with a class specialized in dealing with the low-level issues of the bank.

2. Creating a Template by table probably implies applying the Active Record project pattern. This does not prevent you from, for example, having models that handle session data, such as a shopping cart model, or models that manipulate collections in arrays. The ideal is that a model has no logic of processing requests or vision.

3. I’m going to repeat virtually the entire @Maniero response: The button generates an action/request for the controller. This controller will handle the request, can validate input data, but not handle this data, then passes it to the model (query, change data etc). After the model(s) (s) manipulates the data, the controller sends the model(s) to a view and the view(s) generates the output (a screen, a report, an XML, etc.). This is the standard MVC flow. It just won’t generate a view when you don’t have to present anything. Only it will not consult the model if it does not need any data that is there (remembering that the model may have information beyond the database). Then it is assembled by the whole of the three things, each doing its part.

4. In general these files must be in a public access folder for the client (browser) or subfolders of this folder. But exactly how you organize is at the discretion of a good adequacy study and (like) your or your team.

My suggestion would be that you, in addition to studying the concepts of design standards, study and use a framework consolidated, which already implements good software architecture using these standards. My preference list would be: Laravel, Symphony, Zend Framework; I don’t know but are frameworks consolidated with good community: Phalcon, Yii.