Advantage Data Access Layer

Question

At work, I'm trying to get n-tier model implemented in a large already existing PHP application.

I have to convince my seniors since they don't see the point of an extra DA layer, becasue of performance. The code now queries the Db in the business logic, and calculates in the loop while retrieving the data from the resultset. Low performance cost.

I have tried convincing them by the obvious reasons: transparancy ('we can read SQL'), changing of database ('won't happen').

Their argument is that if it is getting done by a seperate layer, it will mean that a dataset has to be created, and being looped again in the business layer. Costing performance. Also, creating this n-tier model will mean a lot of work which has no 'real' pay.

Is this a performance issue, and therefore a logical reason to say no to a seperate DA layer?

Answer 1

I think you touch an important point: Hand-optimized SQL without an additional abstraction layer can be faster. However, that comes at a price.

The question will probably be: Does the benefit of the additional speed outweigh the benefit of the database access layer e.g. encapsulating the SQL specific knowledge so that the engineers can focus on the business logic (domain layer).

In most cases you probably will find that the performance of a database abstraction layer will be good enough provided the implementation was done by an expert in this matter. If done properly the double buffer/looping can be avoided to a large degree.

I suspect that there are only a small proportion of application (my guess is no more than 20%) where performance is so critical that the abstraction layer is not an option.

But there is also a hybrid solution possible: Use the abstraction layer for the 80% of the modules where flexibility and convenience trumps speed and talks straight to the database in the 20% of the modules where speed is critical.

I probably would vote in favor of the abstraction layer and then optimize performance where needed (which may be achied with means other than talking directly to the database).