Programming Layers

[Gargoyle]

Just wondered how other people go about programming when it comes to large applications. The general rules I have come across are that you would have 3 basic layers:- The Data Layer, The Business Layer and The Presentation layer.

This all looks nice and simple when you set things out on paper, however when you actually come to build your application, the boundaries between layers can be not quite so black and white. So I just want to propose a very simple item and start a discussion to see how others divide things up.

Our example scenario is going to be a website that will store a "Customers" details in a database and provide a page where the details can be updated. To start we'll have a customer class will all the methods and properties for our customer.

Now, this is where the things get a bit fuzzy. Do you have "Load" and "Save" methods as part of your customer class? Or do you have a separate object that will handle storing and retrieving the data via the data layer?

Hope this makes sense... Discuss...

[chucker]

This sounds like MVC to me?

[Brad]

Just wondered how other people go about programming when it comes to large applications. The general rules I have come across are that you would have 3 basic layers:- The Data Layer, The Business Layer and The Presentation layer.
That sounds an awful lot like you're trying to use MVC (http://www.google.com/search?q=model%20view%20controller). :)

[spotcatbug]

Yeah, I would make the customer class abstract away the database interaction as much as possible. That would mean having some sort of load and store built-in to it.

Keep in mind, though, that a "customer" class may not be what you want for your front end, even if you have a table in your database called "customers". You really have to think about how you will be interacting with the back end when you design the front end.

[chucker]

Data ≈ Model
Presentation ≈ View
Business ≈ Controller

[rollercoaster375]

Now, this is where the things get a bit fuzzy. Do you have "Load" and "Save" methods as part of your customer class? Or do you have a separate object that will handle storing and retrieving the data via the data layer?
Data Mapper (http://www.martinfowler.com/eaaCatalog/dataMapper.html) seems to be what you're looking for.

[Gargoyle]

Yes it does sound like MVC, and probably just about every other methodology you care to think of. I am not looking for a specific solution, I just wanted to start some discussion.

Lets say we have our customer object that has been modified by the view. The controller is now going to save it (we'll assume that the data layer has a saveCustomer method). Would you call Customer.Save(), that calls the data layer or do you prefer to have the controller to call the data layer direct?

I think the latter is probably the better way, since it leans more towards re-usable code (The customer object is completely clean from any other layers) and could be reused in other programs. But, having a Save method in the Customer class, can make for quicker application development - Especially, if you take the data layer away, and have the SQL in the customer class.

Example 1 (pseudo code, not real PHP)

class Customer
{
# internal variables
protected id;
protected firestName;
protected lastName;

Save(){
sql = ("UPDATE customers SET firstname = '%s', lastname = '%s' WHERE id=%d",
this.id, this.firstName, this.lastName);
db.Update(sql);
}
}


This is the most common way I do things. As I see it, even if my underlying storage changes from SQL to XML (eek!), then I would have to change the save methods for my classes, but the rest of the application would be unchanged.

[chucker]

Would you call Customer.Save(), that calls the data layer or do you prefer to have the controller to call the data layer direct?

The controller would call the data class's save method. The controller wouldn't know anything about how saving actually works (e.g., where it saves to and in what format).

But, having a Save method in the Customer class, can make for quicker application development -

That's a common fallacy. Constructing clean code separation takes longer, but actually developing once you do have that is a lot faster. So it's a steeper curve at the beginning, but once you're there, you definitely benefit. Your code becomes more maintainable.

Especially, if you take the data layer away, and have the SQL in the customer class.

Meep! Design mistake. Regardless of your database backend (be it flat files, a local database, a remote database, SQLite, Oracle, FileMaker, whatever), you should always have a data class. Your controller and model classes won't know anything about how that data class actually works, which will make your app agnostic of the data format. Wanna switch to a different database format? Just change the data class's implementation (whereas its interface stays the same!). In fact, a class cluster can allow you to support multiple different formats at once, all sharing the same interface.

[azcoder]

Rather than embed data access code in your customer object, an alternate design might utilize some other mechanism to store and retrieve objects from a data store. This simplifies your object model, and centralizes persistence accountability.

For example, the controller could use some kind of EntityManager to retrieve any and all objects from storage. The objects themselves are completely oblivious to how they are stored.

This let's you concentrate on building rich Domain Objects without worrying about persistence at all.

The new Java Persistence API uses this approach. Several Object-Relational Mapping frameworks (like Hibernate and iBatis) also take this aproach.

Clearly there is no right way for doing this - there are just various approached that have different pros and cons.

Happy Coding

[Gargoyle]

Here's another one that always drives me mad. Lets say you have an Organiser and a list of events (a common one to many relationship). So in your database you have a table of organisers, and a table of events. In each event you have the ID of the organiser for that event.

So, in your application you have an organiser class, and an event class. Now does the organiser class have a list of event objects or does the event class have an "owning" organiser object?

[pmazer]

So, in your application you have an organiser class, and an event class. Now does the organiser class have a list of event objects or does the event class have an "owning" organiser object?

It depends on how you need to access them. If the organizers need to know which events they have, then give it to them. If the events need to know who the organizer is, give it to them. If both need the information (most likely), give it to both. Make your job as a programmer as easy as possible. Optimize later.

[scratt]

Spaghetti is king! :p

[Kickaha]

shut up, you. :p

:)

Damned machine code lover!

[Gargoyle]

pmazer, both need it but you also suggested the one thing I know is bad. Circular Dependancy!

What happens when you come to serialise your class and you have organiser with a list of events, and each event has an organiser, who has a list of events.... etc.

But after much pondering today, I decided that I am too good! :) I always over analyise things and can always spot the bits of web applications that are going to do more requests to the database and try and reduce that number. Hence getting myself all wound up in things like this!

I am actually going to do it the way is most natural from outside the programming world. I am going to have the list of events as part of the organiser class even when I am working with a single event! With a bit more thought I should be able to save even more database lookups by making more use of temporary session storage.