Multi-Tier in PHP..the right way?

Question

I have a specific question, that could use a general answer... When building Multi-Tier applications in PHP, does everything have to be done in the Business Logic layer, or can any layer do work... Example, Lets say I'm building an application that shows user information (from the database) on the presentation layer. Should I use the business layer to simply pass the data to the presentation layer, or just get the information from the database directly within the presentation layer. Should the presentation layer be used JUST for presenting the data, the accessor layer used JUST to get the data, and all the work be done in the business layer?

Also, speaking of the different layers, is it best to do things procedurally, or using OOP ( like using includes to show the templates vs using a class to include the templates, validating data procedurally vs using a class, or functions vs classes for getting the data from the database, etc. )

As you can see, I'm trying to understand how things work, and the best way to do things. That being said, if you have any advice, or any general tips on the subject... please leave them..

Thanks

Answer 1

Web applications and N-tier is interesting, mostly because the notion of N-tier has expanded with the widespread adoption of JSON and AJAX, or Flash and XMLRPC. This chart on Webopedia displays a staggered blue line that expresses this well. To summarize: your business, accessor, and presentation logic not only could exist on the server--but in some cases, right in the browser. The intention of N-tier, however, is separability. If you need to change out your UI or your database, or add other UIs, you shouldn't be affecting your business logic. And this is what would determine your API--anticipating the day your HTML and CSS are discarded for Flex, and MySQL is changed out for Oracle.

This is requirements determined, and in some web applications I've used, variations of N-tier are used simultaneously. Take for example LyrisHQ (an e-mail ASP). They have a customer web application. Recently, they have stared pushing their Flash based application. This clearly is shipping a lot of data right to the browser, and there is probably a bit of business logic duplicated in the Flash UI. They must maintain both applications, however, since either one is necessary for different (and overlapping) requirements.

Most common PHP applications are not considering shipping much unformatted data to the browser. But if you were, this would inform you very quickly how you would want to design your APIs. Very likely, you would want controllers that could talk XMLRPC, REST, or SOAP...in addition to a similar internal controller class that your PHP presentation templates used. This would strictly mean for a simple web login page, you would have a PHP template for the login form that talked to a LoginController class. An XML interface would likewise use the same LoginController class. Just as you would assume that you would be bonkers to write SQL into an Ajax request...you would be strictly avoiding writing queries into your presentation templates.

Business layers can be more or less strict, because often there is never a requirement to switch brands of database back-end. In a strict N-tier design, how your business objects would talk to your database would be as if you could switch from MySQL to MS SQL without rewriting the Business tier. Sometimes this is done by modeling objects for each table (Table Gateway), each row (active record), each join, or each transaction. This is where something like PDO or PHP-ADO are useful, but insufficient for complete isolation. ORM/Persistence layers in Java like Hibernate demonstrate better this kind of isolation, often by providing an Object Query Language (OQL).

Myself, I am presently undertaking a back-end transition from a MySQL based PHP application over to an MS-SQL one. The application has only ever used direct SQL queries. Imagine choosing how to take a series of queries in a class and either abstracting them, or subclassing, and hopefully not altering the business logic. At the very minimum, you will want to make all your SQL calls indirect. (S.O. post on PHP ORM.)

And finally, to your question about OOP: use it how you must to fulfill your requirements. My personal technique is to start with logic right in a PHP presentation template for a few minutes to get the ball rolling, pretty soon I'll refactor that into a class and a template. If I have common ideas, I break out routines into shared classes, striving to preserve the DNRY principle. (A S.O. post on that here. OOP is not a fundamental requirement for N-tier design. DNRY is very important for keeping your code maintainable, tho. Often deadlines and scope-shift destroy an API. Refactor it until you get what you need to keep going. I bet OOP will help get you there.

Answer 2

I once read something saying that big models (business layer) should be preferred over big controllers (accessor layer).

Also: It really depends on the project. In my eyes it doesn't always make sense to use OOP for everything (probably not everyone will agree here), especially in scripting languages like PHP it oftentimes is easier to simply do validators as functions...

Answer 3

I definitely advise you not to have database calls in the presentation layer, that would defeat its purpose.

There are different approaches to multi-tier architecture and they have different recommendations.

Zend Framework that i've worked with is usually of the form Fat model/Thin controller variant.

If find this article Notes on Choosing a PHP Framework to be pretty good at comparing (in this case) CakePHP to Zend Framework.

The biggest difference in my opionion is the convention-over-configuration approach taken by CakePHP which is very different from configuration focus in Zend Framework.

By using a framework, which makes a lot of sense if implementing a multi-tier architecture, your are in a way forced or at least pushed into using OOP, which is not a bad thing.

You could of course implement, say a 3-tier architecture with pure functional calls, but it would not scale that well based on my experience.

For a website the MVC pattern which actually is quite different because of the way the tiers communicate, is a good choice.

The difference between a "normal" 3-tier arch and the MVC pattern is that the view has access to both the controller and the model layer, where as the presentation layer only has access to the logic layer of the 3-tier arch.

Answer 4

i agree with what Franz said, especially about preferring larger models over larger controllers.. you can also use a rule of thumb to help distinguish where code should go: if it has anything to do with the UI structure/flow, put it in the controller; if it's pure business logic, it goes in the model..

i'll add that as a Java developer that had a lot of experience with Struts before testing out the PHP waters, it took me a while to understand how to apply MVC ideas to a scripting language.. i personally found that using a system like CodeIgnitor helped a lot.. it provides the framework, much like Struts, and encourages good MVC patterns..

Answer 5

My world looks like this:

DB1 <- Model1 to provide accessor functions, data integrity, business rules for this data set DB2 <- Model2 to provide accessor functions, data integrity, business rules for this data set

Controller : Controls data flow to views, filters/organizes data from views. Implements business rules for the given application. Knows the business rules between Models.

Views: Nothing more than templates that display data provided by the Controller. Pass all data to the controller. Has no knowledge of Model1 or Model2 or the the business logic that governs them.

Answer 6

I recommend doing some research on Design Patterns as this is the missing piece of your puzzle. There are a number of PHP-specific books that cover this topic (the ones from APress are good) as well as the 'bible' of Design Patterns: "Design Patterns: Elements of Reusable Object-Oriented Software"

Answer 7

Let's wait for more stable version of Doctrine2.

It's being developed with persistence-ignorant domain object philosophy. It will be much easier to develop multi-tier application with help of this framework.