Application Design In Php

[Craige]

PHP:Main

The Art of Application Design in PHP

For years, web development has been thought of as the little sister of desktop programming. This can largely credited to the to the lack of design required, or even suggested to write any type of application.. In these days, one can pick up a language, such as PHP, and be able to write something significant, with next to no knowledge of the language, or application design. This article is my attempt to bring the art of application design to those who read. It is my opinion that such a practice should be with all applications you write, and it should be done right.

This article will not contain code examples. By me not posting code snippets, it forces you to read, and comprehend the concepts described here, rather then just copying code mindlessly. I hope this article helps you learn/expand your knowledge of application design, as it applies to PHP.

Throughout this reading, we will be discussing many things pertaining to object oriented programming. It is strongly advised that you have background knowledge on this subject. That being said, let's get started.

Why Application Design?

Application design is a key factor to writing successful code in any language; PHP is no exception to this. Those who understand application design, are able to write better, more efficient, robust code. It is because of understanding application design, that programmers are able to make such drastic changes to their programs, with no error. Can you change the entire layout of you website without ever touching your code? How about changing the way databases queries are handled on all pages, by editing only one file? If you answered yes, I solute you, but I still suggest you read this article. I'm sure it will contain new ideas you may never have thought of.

Design Patterns.
What's a design pattern? Well, I'm glad you asked. A design pattern is a widely accepted formation of code, that is proven to solve broken design concepts. These patterns, relate directly to object oriented programming. If you program in OO regularly, you're probably using many design patterns without even knowing it. This is because there is nothing special about these patterns. They are formed from the mind of a programmer, just like yourself. However, they have had extensive research done upon them, to prove they effectively solve a specific problem. There are many patterns publicly known today. If you would like to research design patterns, a Google search will do you well.

The Problem
In this article, I would like to specifically discuss one problem that plagues the web today. This problem is one of complete miss-design. Many pages online to day suffer from this problem, and don't even know it. 80% (figurative guess) of websites are guilty of mixing all of their content together in one page. They embed xhtml, database calls, and program logic together in their pages. “But wait,” you say ”PHP was designed to allow this. How is it a bad thing?” Lets explore this.

Have you ever wanted to re-design your website, but held off in fear of all the work? This is the case with many websites today. Web 2.0 is here, and with it came web standards. Sites that were created before the era, are often riddled with invalid XHTML, and neglect to fix such errors, due to the tremendous work load involved. It's a terrible issue for web developers to deal with, and it's all due to bad application design, and it is why such a concepts needs to be enforced in new web applications rising to meet the web.

The Solution.
The solution, is good application design. If you design your PHP wisely, you are able to make drastic changes to how your site looks, feels, and functions, without fearing some new bug popping up. Mind you, bugs will always exist, but by designing your PHP based applications properly, you remove many chances for a bug to creep in. Let's take a look at the “proper” way to structure your code.

As you may have gathered already, my prime concept here is separating output, logic, and data, where the output is XHTML, the data is input from the user (MySQL, forms), and the logic, is obviously, any business logic that requires your program to “think”. This is often a hard concept to grasp for new programmers, but one you must grasp none the less. Most people are able to separate output from logic, but run into trouble when trying to separate all three from each other. For such a system, we should separate the three different areas into “layers”(/objects), thus having a presentation layer, a data abstraction layer (DA layer), and a logical layer. One key thought to keep in mind when designing such a system, is the following guidelines:

1) The presentation layer should have no knowledge of the logical layer, or the DA layer. For all it cares, you are directly calling methods with parameters.
2) The DA layer should not have any knowledge of the presentation layer, or the logical layer. For all it cares, it's working on a desktop getting information for an instant messenger client.
3) The logical layer should not have any knowledge of how to present the output.
4) The logic should have no knowledge of how to get the data.

If you can comprehend a system with these specifications, you are well on your way to having a beautiful design.

So, where should we start designing such a system? The logical layer is always a good choice. The reason for this being that the logical layer is the only layer that has knowledge of the other layers existence. Remember, the DA layer and the presentation layer have no knowledge of each other; they work completely unaffected by one and other. Therefore, it only makes sense one would start with the logical layer.

The logical layer contains any and all program logic. It is essentially the page, with calls to the presentation layer, and the DA layer. How you set up this layer is completely up to you, though the MVC design pattern, which this article is being based off of, has each page assigned to a method. This allows for easy, clear separation of pages, and allows an entire group/category(essentially, the object) of pages to be looked at relevant to each other, with one single file. A new group can be created simply by creating another object, and a new page by creating a new method. This method of constructing the logic layer is strongly recommended.

The next step is a toss up bet ween the DA layer, and the presentation layer. Beings both are separate from each other, it does not matter which you tackle next. For this article however, we will talk about the presentation layer.

The Presentation layer is the layer responsible for displaying all data your site generates. Nothing should be returned to the browser that is not a result of this class (with the exception of PHP errors). This layer can often be referenced as the “templating engine” in many cases. It deals with templates, and makes sure no invalid data gets out, and also makes sure that the logic layer does not have to directly interact with any template files, or output. Remember my comments about changing the entire layout of your site? It is the presentation layer that allows for such actions. Because the logical layer never touches a template file, you can change the content of the template's all you want, and need only change the presentation layer (if even required at all).

This layer needs only one copy, unlike the logical layer which can have many for each different group of pages. It is also recommended that you have a layer to interface with user input (ie: forms). If you wish not to create a separate layer for it, this would be the perfect layer to include it in (though I recommend a separate layer).

[Craige]

Now, it's time to talk about the DA layer. In the past, you may have grown accustom to coding all your SQL calls and functions right in to, what you now know as, the logical layer. As of now, this will change. Coding all this strict information calls into your logical layer makes it very difficult, if not impossible to change the way your data is handled. What would you do if you wanted to change from a MySQL database, to a MSSQL database? You would have to go through all your scripts and change all your queries, and functions, to use the new syntax and functions. Very time consuming. This is where the DA layer comes in. A properly coded DA layer will allow you to change the data source almost seamlessly. All that needs to change is the DA layer, and the rest of your scripts can remain untouched. How? Let's explore that a little.

Say for your DA layer, you know you will always want to find, and Send stuff to and from your data source, at a minimum. You could create two methods, Find() and Write(), which could accept a number of non source specific parameters, such as(Find) char field, mixed arr match, and int num. With these non source specific fields, you could build a query in Find, instead of having your logic layer doing it. That way, if you wish to switch data sources, you simply need to change you DA layer to build a different query based on the old parameters, but for the new source. And therefor, you never have to go back and change your logic layers if you need to change your data source.

Now that you have that part, it's time to get a little more complex. In order to completely separate your logical layer from your data source, you need to create a DA layer for every logic layer. In these DA layers, should be methods specific to the logic layer it corresponds to. IE, if you were making a forum, you might have a method called GetPost(topic_id) which calls Find() to get that post, and return it to the logical layer. To avoid unneeded code repetition, you should have a base DA class, which is inherited by each DA layer. The base class would contain generic methods like Find(), and Write(), while the DA layer would be more specific to the logical layer.

Pulling them together
Now that you have a concept of how to separate these layers, I should also give you a concept of how to pull them all together for easy interaction. This is done rather easily in most cases, by having the constructor of your logical layer do all the work for you. Provided you name all your classes appropriately, you can have this done with no work at all. Simply create a private variable in your logical layer which will hold your DA layer, and also one for your presentation layer. The presentation layer will always have the same name, as there is always one copy. The DA layer on the other hand, is a little different. As I said, you should have one for each logical layer. I recommend naming them something like so: logicname_model (a model is what you call the DA layer in the MVC pattern) where logicname is the name of the logical layer it corresponds with. You should also save all your DA layers in one folder, with the name of the class it contains.

That said, instalizing your DA layer is as simple as calling:

$class = __CLASS__;
inculde $class.'.php';
$this->DA = new $class();

more or less anyway.

Conclusion

That concludes this article on the art of application design with PHP. Although it was rather lengthy, I hope you were able to get something out of it. I would recommend you researching the MVC design pattern to continue what I have attempted to teach here. It really pulls together everything I have been explaining.

Preliminary Reviewers: Erwin, Dan, and DFox

Digg it!

[d2312564]

AWESOME tutorial.

Personally I think tutorials that teach concepts are more important than tutorials that just show code because knowing the concepts is the key.

Excellent job.

At 1/16/07 10:13 PM, Craige wrote: Digg it!

Done :)

[Bizarro]

At 1/16/07 10:13 PM, Craige wrote: Preliminary Reviewers: Erwin, Dan, and DFox

Sheesh, some reviewers

solute you

salute you

But on a serious note, that was very well written and explained. It didn't exactly tell me how to do all of it but certainly made me very interested in pursuing it...which I will do.
(Sigh, my site is never going to get done now :P )

[Craige]

At 1/16/07 10:16 PM, DFox wrote: AWESOME tutorial.

Personally I think tutorials that teach concepts are more important than tutorials that just show code because knowing the concepts is the key.

Excellent job.

Thanks. That's what I was going by when I was writing it

At 1/16/07 10:13 PM, Craige wrote: Digg it!

Done :)

:)

At 1/16/07 10:27 PM, Bizarro wrote:

At 1/16/07 10:13 PM, Craige wrote: Preliminary Reviewers: Erwin, Dan, and DFox

Sheesh, some reviewers

I know, eh.

solute you

salute you

But on a serious note, that was very well written and explained. It didn't exactly tell me how to do all of it but certainly made me very interested in pursuing it...which I will do.
(Sigh, my site is never going to get done now :P )

Thanks. I think It could have been written a little better, but oh well I guess. If anyone spot's any errors, let me know please. I keep a hard copy of articles on my hard drive, and I'd like to update any errors there.

And it defenatly is an area to pursue. When you finally get your foot in the door, you look back and laugh, because you can then see all the problems with your previous methods.

[elbekko]

At 1/19/07 03:06 AM, Zendra wrote: Nice work Craige!
I bet half of you don't even know who this "Erwin" is! ;)

You? :P

Looks like a nice tutorial, I'll definately read through it tonight.