Organization of PHP code

Asked

Viewed 490 times

2

I’m working on a PHP project where several tables relate to several tables, so how should I organize the controllers and Daos,

split files by table - employees, sales, customers, ...

or

group by shares - employees + sales (employee actions plus employee actions related to sales), customers + employees (customer actions plus customer actions related to employees), ...

If I group by table I’ll have more organized code and more code reuse, but grouping by actions makes it faster as I don’t need to transfer data between controllers and I don’t need to call more than one DAO.

This difference in performance is significant, considering that there are few accesses to the application?

When to know when one is more advantageous than another?

php project-organization dao-pattern
  • 4

    Look, the fact is that there are several ways to organize your code, in addition to the two you cited... I recommend that you look beyond the technical part, the people who will work on the project in the future. Whichever shape you choose, choose for the ease of climbing and maintaining at the source. Unfortunately they do not do as much as they should, and I think your question is commendable. Congratulations!

  • @Diegosantos could assemble a response with other forms of project organization?

  • I published an answer as you requested. However, in my experience. It is not a universal truth, but I believe it can be useful to you. Good luck!

2 answers

4


As we know, there are several ways of organizing scripts in a project. All of them have positive and other negative points when faced with the need.

I will cite below ways in which I have seen and what I think of each, by MY experience.

Arrange by tables:

It is a direct and easy to understand way. However, this is for those who already know the context of the application. If it is something that desenv doesn’t really know it will get lost in the database and source.

Organize by domain:

Today I work a lot with MVC and DDD. I confess that I adapt better with DDD. It makes more sense for me to organize the system in domains.

However, sometimes we add too much complexity to the structure of the project, if we do not follow this pattern correctly. I recommend this.

Layering

Honestly, I’ve seen programmers get lost more in this model than in others. It’s very easy for systems to be born with this pattern but with time get messy, just because each programmer understands a functionality in a different layer. This way, in a short time, the system becomes a "monster".

With regard to the DAO. There is also another access standard that is repositories. Instead of creating objects that directly access data, repositories are created that perform queries. In this case, you can create repositories adhering to the business rule and not abstractions of the created templates.

Example: When we are creating a report we do several consultations in the same context. It’s easy to predict that the best thing to do is to bring all the information at once and unlock the data on screen. Correct? In this way, a repository could be created that meets this need for this report, for example, using the templates as patterns, parse, only.

Important:

This is not a silver bullet answer! There are several standards out there and regardless of which choice, think about the lifecycle of the software you’re producing. You won’t be the only one working on it. Knowing the company you are working at, it is possible to reasonably predict the profile of the people who will be in your place in the future. This way, you can choose a standard that is easy to maintain and easy to scale.

  • Could explain the organixation by domain?

  • It’s the DDD organization. Drive Domain design. See explanation: https://answall.com/questions/19548/o-que-realmente-%C3%A9-ddd-e-when-it-applies

1

To try to organize the project in the best way possible (more reuse of code in order to interfere as little as possible in the performance) divides the project into 4 parts:

  1. View (interface, divided by actions)
  2. Router (takes care of the redirecting part, divided by actions)
  3. Controller (Business rules, divided by table)
  4. DAO (Database access and SQL execution, divided by table)

The view sends a request to the router (for example, user registration)

The router stores data passed via $_GET or $_POST and calls the controller functions

Controller functions validate and enforce business rules and call DAO functions

DAO functions only execute SQL and can return 3 values:

  1. false: if the execution fails
  2. true: if the INSERT, UPDATE or DELETE succeed
  3. Array: if the SELECT succeed

The controller checks the DAO output, if the DAO fails, creates an error message session and returns false to the router or, if DAO succeeds, return true or a Array

Router checks the return and redirects or to an error page (erro.php, for example) or to the correct page

This model has as main advantage the reuse of business rules and Sql scripts, having only code repetitions in redirects (header("location: ...")), so it is also not necessary to pass data between controllers

Browser other questions tagged php project-organization dao-pattern

You are not signed in. Login or sign up in order to post.