is my php architecture solid?

Question

I'm trying to design a solid server side architecture and came up with this :

http://www.monsterup.com/image.php?url=upload/1235488072.jpg

The client side only talks to a single server file called process.php, where user rights are checked; and where the action is being dispatched. The business classes then handle the business logic and perform data validation. They all have contain a DataAccessObject class that performs the db operations.

Could you point the different weaknesses such an architecture may have? As far as security, flexibility, extensiveness, ...?

Answer 1

Your architecture isn't perfect. It never will be perfect. Ever. Being perfect is impossible. This is the nature of application development, programming, and the world in general. A requirement will come in to add a feature, or change your business logic and you'll return to this architecture and say "What in the world was I thinking this is terrible." (Hopefully... otherwise you probably haven't been learning anything new!)

Take an inventory of your goals, should it be:

this architecture perfect

or instead:

this architecture functions where I need it to and allows me to get stuff done

Answer 2

One way that you could improve this is to add a view layer, using a template engine such as Smarty, or even roll-your-own. The action classes would prepare the data, assign it to the template, then display the template itself.

That would help you to separate your business logic from your HTML, making it easier to maintain.

This is a common way to design an application.

Another thing you could do is have another class handle the action delegation. It really depends on the complexity of your application, though.

The book PHP Objects, Patterns and Practice can give you a real leg-up on application architecture.

Answer 3

I see a couple of things.

First, I agree with others that you should add a view layer of some kind, though I am not sure about Smarty (I use it frequently and I am really having doubts these days, but I digress). The point is you need to separate your HTML somewhere in a template so it's easy to change. That point does not waver if you use a lot of AJAX. AJAX still requires you (usually) to put divs around the page, etc. So your layout should be separated from processing code.

The second thing I would throw out there is the complexity of your data model matters. If this is a straightforward CRUD application over an existing, or fairly flat, db model, you are probably fine with these db access classes. But, the minute your model gets to be more complex, with hierarchies or polymorphic in any way, this will break down. You'll need a more robust ORM of some kind.

Your "controller/dispatcher" methodology seems sound. The switch statements avoids the need for any kind of URL -> code mappings, which are a pain to manage and require caching to scale.

That's my $0.02

Answer 4

From a security perspective your class and action are coming in from your post variables and this can be dangerous because you should never trust anything coming from the user. Assumingly your class/action will look something like this:

class1
{
  action1.1
  action1.2
  ...
  action1.N
}

class2
{
   action2.1
   action2.2
   ...
   action2.N
}

As an attacker my first place to look would be getting into a state where an action doesn't match to it's appropriate class. I would try to submit class1 with action2.1 instead of action1.1.

With that said, my assumption is that you've already got some form of validation and so this wouldn't happen. Which leads me to my original post: If your architecture works for you, then it works for you. Take a look at the things which you're asking about: security, flexibility, extensibility and evaluate them yourself. Find your own flaws. If you don't know how to evaluate for security/flexibility/other read up on the subject, practice it and apply it.

You'll become a better developer by making mistakes and then learning from them (except missile guidance software, you only get one try there.)

Answer 5

Since others have suggested various changes like adding a view layer, etc. let me concentrate on the various criteria for a good architecture:

1. Extensibility: Usually, the more abstract and loosely coupled the architecture is, the more extensible it is. This is exactly why others have recommended you use a view layer which would abstract out the presentation layer templates for each class:action pair into its own file.

2. Maintainability: This goes hand-in-hand with extensibility. Generally, the more extensible the architecture is, the more maintainable it is (take that with a grain of salt because it is not always the case). Consider adding a model layer below your model logic layer. This would help you swap out your data access logic from the model business logic.

3. Security: The downside to the architecture you have posed is that you really need to invest in security testing. Since all your redirecting/routing code is in process.php, that file has a lot of responsibility and any changes to it may result in a potential security loophole. This isn't necessarily wrong, you just need to be aware of the risks.

4. Scalability: Your architecture is balanced and seems very scalable. Since you have it broken down by class:actions, you can add caching at any layer to improve performance. Adding an addition data access model layer will also help you cache at the layer closest to the database.

Finally, experiment with each architecture and don't be afraid to make mistakes. It already seems like you have a good understanding of MVC. The only way to get better at architecting is to implement and test it in the 'real world'.