Good practices for MVC in PHP

3

I'm learning more about using MVC using PHP, and after seeing some classes and articles on the internet I've had some doubts about using them, since I've found classes that present the same case differently. I know there is no perfect form, but I would like a clarification of what would be the best practice to take.

1) Is the connection to the DB to be made through controller , model or some other configuration file? - I found articles in both.

2) Do I have to create a model per table? - Let's say I have both Table1 and Table2, and I need a SQL that relates the two, I have to have a separate model for each of them, or in model in> of Table1 do I query with JOIN between them?

3) I have a button in a view that returns a filled form for example, this "code" form (being it in HTML with DB data) model , controller or a view that only has this form?

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

    
asked by anonymous 20.04.2016 / 13:53

2 answers

4

MVC is a design standard.

Design patterns should be employed to solve a common and standardized "problem", allowing the application of proven solutions and / or standardization of architectures, allowing a team to work in a homogeneous way.

In this way, the MVC design pattern was created to solve the problem of logical organization of a project, using separation by responsibilities, so the Melo is responsible for manipulating data and / or the logical part of the application, (V) iso is responsible for applying all information output logic - it can be a "screen" in html or the generation of XML or JSON responses; (C) the controller is responsible for orchestrating models and views by functionality, it is the one that receives the action requisitions, identifies which models must handle the data for a request, and which views should return the request output / response. p> It is also possible to apply other design patterns together to solve several "problems" - Front Controller to centralize the requisition treatments, allied to the Dispatcher to identify and instantiate the correct controller to handle a request; DAO / ORM / Active Records to handle persistent data manipulation; Services Layer for agnostic separation of application logic, etc.

So there's a need to apply the concepts correctly.

Regarding your listed questions

  • The model should handle data, this is the definition, I do not think correct in the model, for example, make the connection with the bank, it is ideal to use dependency injection for this purpose with a class specialized in dealing with the bank's low-level issues.

  • Creating one template per table probably involves applying the Active Record project pattern. This does not stop you from, for example, having templates that handle session data, such as a Shopping Cart Template, or templates that manipulate collections in arrays. The ideal is that a model has no logic of handling requests or vision.

  • I'll repeat pretty much the @bigown answer: The button generates an action / requisition for the controller. This controller will handle the request, being able to validate input data, but not manipulate this data, then pass it to the model (consult, change data etc). After the model (s) manipulate the data, the controller sends the model (s) to a view and it is in charge of generating the output (a screen, a report, an xml, etc). This is the default MVC stream. It just will not generate a vision when you do not have to present anything. You will not only query the model if you do not need any data that is there (remembering that the model may have information beyond the database). Then it is assembled by the set of three things, each doing its part.

  • In general, these files must be in a public folder for the client (browser) or subfolders of this folder. But exactly how you organize it is at the discretion of a good study of suitability and (taste) yours or your team.

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

        
    21.04.2016 / 03:10
    5

    There is no such good practice business. There is right or wrong for every situation. Only qualified experience, more than quantified, will provide a basis for achieving this.

    Most of those classes out there are cake recipes that hinder the person's creativity, sell the idea that there is only one right way to do it, and often contains a lot of mistakes.

  • Where the connection goes depends on the overall architecture. Some will say that it is in the model (usually not within the data class), it is not wrong, others will say that the model itself is just the data classes. The connection will hardly be in the controller. I do not see much sense in this, I can not imagine a reason to do this. If you are going to use a configuration file or not, it is a decision that has nothing to do with MVC.

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

  • The button generates an action for the controller. This driver will query the template. And in the end it will generate a vision. I do not know if I understand the doubt, but this is the MVC. It is essentially so. It just will not generate a vision when you do not have to present anything. You will not only query the model if you do not need any data that is there (remembering that the model may have information beyond the database). Then it is assembled by the set of three things, each doing its part.

  • Organizing files you do the way you think best, MVC does not determine where to per. Standards only determine what is relevant to solving a specific problem. You can change what you want in the default if you do not change the result if it does not create a problem for the solution. Standards can even be considered cake recipes, but since every recipe does not have to go right. Of course, if you do not know how to cook you will have a harder time doing it right if you get away with the recipe. So my advice is to learn to cook.

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

        
    20.04.2016 / 14:10