Layers of Programming (Part 1)

One of the struggles I've had in OOP is figuring out how to separate the user interface from the data access.

**EDIT: I've posted a better blog on this concept. It can be found here. Check it out if you're interested.

When I was coding on a fairly regular basis in PHP, my user interface and data access layer, along with the business logic, were all over the place.

Now, if you're just doing brute-force programming, by definition, it doesn't really matter how you solve problems with programming, as long as you solve the problem. Note, if you have to maintain the code, brute force programming is basically an invitation to the requirement of redoing work you've already done. If anyone else has to maintain your code, their likely conclusion will be that they'll have to replace your code.

But if you have to program at a somewhat more professional level, or if you're a code-junkie like me, you're going to have to get proper separation of various layers of your application.

I've found that there are a number of ways to solve this problem. One way is to simply follow the axiom that one class does one thing (also referred to as the "Single Responsibility Principle"). There are also pre-written design patterns like MVC (Model View Controller) that solve these problems.

I'm a more literal type of guy. I've always found MVC to be overly complicated for what I want to do.

My solution to the problem of layer separation is to simply focus my classes to fit into one of three layers: user interface, business logic, and data access layer.

I'll speak to each of these layers in subsequent posts, but I'll give a few principles that each of these layers follow:

Data Access Layer: Anytime the application has to leave itself to fetch data from some source, whether it be a text file, XML file, or database, the business logic layer asks for the data, in some way, shape or form, from the Data Access Layer. Certainly, if I did happen to have data access from multiple sources, I would separate these into separate classes, perhaps using inheritance or abstraction.
One of the other principles I follow is to make the Data Access Layer as simple as possible, often reusing the same 1, 2, or 3 methods hundreds of times.

Business Logic Layer: Far and away, the most bloated layer. And it makes sense that this is so. The data access layer, and in a lot of ways, the user interface layer, are often interchangable throughout applications, if you build the business logic layer correct, and are consistent in your coding style. But Business Logic really defines the application, and may be comprised of anywhere from 1 to 1000s of classes, depending on the complexity of your application. One nice thing though is that, if the data coming back from the data access layer is in consistent, predictable format, you can take opportunities to reuse code to provide a large range of functionality. It really comes down to well-thought-out design.

User Interface Layer: I've been trying to come up with deas of how to minimize the user interface layer, as far as number of lines of code required to make it happen, and I keep coming back to the idea of having configurable forms, and the storage of those forms stored in a database. This way, you have an extensible (low effort to make changes and advance the layer) layer, that is ready to deal with all the different views you want to present to the end-user.

The ideas of how to separate these layers, and the eloquence of the solutions really come down to style. I'm ok with not having the most elegant solution in this respect, because it works, and it keeps my code maintainable, and easy to read.

Digg It