Organization of PHP code

Question

Organization of PHP code

Navigation

#1 by (4 votes)
#2 by (0 votes)

2

I'm working on a PHP project where multiple tables relate to multiple tables, so how should I organize controllers and DAOs,

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

or

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

If I group by table I will have a more organized code and more reuse of code, but grouping by actions makes it faster as I will not need to transfer data between controllers and I will not need to call more than one DAO.

Is this performance difference significant, considering that there are few accesses to the application?

When to know when one is more advantageous than another?

php

asked by anonymous 14.03.2018 / 20:47

2 answers

0

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:

View (interface, divided by actions)

Router (takes care of the redirect part, divided by actions)

Controller (Business Rules, divided by table)

DAO (SQL access and database execution, divided by table)

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

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

The controller functions validates and applies the business rules and calls the DAO functions

DAO functions only execute SQL and can return 3 values:

false : if execution fails

true : if INSERT , UPDATE or DELETE succeeds

Array : if SELECT succeeds

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

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

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

03.04.2018 / 01:54

Print in ascending order the first natural n's that are multiples of i or j or both transform: translate is compatible with which browsers?

score 4 · Accepted Answer

As we all know, there are several ways to organize scripts in a project. All clear have positive and negative points to the need.

I'll cite below ways I've seen and what I think of each one, from MY experience.

Sort by Tables:

It's a straightforward and easy to understand way. However, this is for those who already know the context of the application. If it is something that the developer does not really know, it will get lost in the database and the 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 into domains.

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

Arrange by layers

Honestly, I've seen programmers lose themselves more in this model than others. It is very easy for systems to be born with this pattern but over time they will be messed up just because each programmer understands functionality on a different layer. This way, in a short time, the system becomes a "monster".

With regard to DAO. There is also another access pattern that is that of repositories. Instead of creating objects that access data directly, you create repositories that query. In this case, you can create repositories adhering to the business rule rather than abstractions of the created templates.

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

Important:

This is not a silver bullet response! There are several standards out there and regardless of which choice, think about the life cycle of the software you are producing. You will not be the one to work on it. Knowing the company you are working with, and you can reasonably predict the profile of the people who will be in your place in the future. In this way, you can choose a standard that is easy to maintain and easy to scale.