How to use bll, dal and model?

Question

In my company I must use a Bll, Dal and model layer for creating applications with a database.

I've learned at school that every databasetable should be an object in my model. so I create the whole model of my database. Also I've learned that for every table (or model object) there should be a DAO created into the DAL. So I do this to.

Now i'm stuck with the BLL classes. I can write a BLLclass for each DAO/ModelObject or I can write a BLLclass that combine some (logic) DAO's... Or i can write just one Bllclass that will manage everything. (this last one I'm sure it aint the best way..)

What is the best practice to handle this Bll 'problem'?

And a second question. If a bll is in need of tablecontent from an other table where it aint responsible for, whats the best way to get the content? Go ask on the responsible BLL or go directly to the DAO?

I'm struggling with these questions the last 2 months, and i don't know what is the best way to handle it.

Answer 1

You should start with what you need to make work the app.

For instance: "I need a web ui for user login"

1. So I need a controller that use a model to check nickname and pass
2. Then I need a bll object to do the logic for check nickname and pass
3. Then I need a dal object to access the database to retrieve user info

If you not start to think like that (a top to bottom aproach) then you are going to write a lot of code that is never going to be used.

note: if the dal is orm mapping or not is anecdotal. Also if the model use a bsl or the bsl use a model. IMHO.

Answer 2

Ive learned at school that every databasetable should be an object in my model.

So you did not learn object orientation? Inheritance? Mapping multiple object types to one table? Only the simple "stupid" every table is one object? There are more logical ways to map objects. All with their own different good and bad sides (i.e. you choose them depending on circumstances, among them the number of fields in each object).

Also I've learned that for every table (or model object) there should be a DAO created into the DAL.

Go to the school, demand the money back - they were idiots. Generated DAO's are bad to start with. Gets worse to have one per object. CONFIGURATION trumps CODE - a generic DAO can handle x different objects, depending on configuration. Lot less code to test and load. This is how proper frameworks do it (like Hibernate/NHibernate). You can esily write a DAL that has about half a dozen methods it exposes during operations and handles an unlimited number of objects. At start, you tell every DAL which object it has to handle and how, so it can generate the proper SQL etc.

What is the best practice to handle this Bll 'problem'?

Back to school, learning basics. Read up on O/R mappers. Hibernate / NHibernate (you dont name the langauge you use), Toplink etc.

If a bll is in need of tablecontent from an other table where it aint responsible for, whats the best way to get the content? Go ask on the responsible BLL or go directly to the DAO?

Depends on architecture. In general, a business object will come from a factory, and should only talk to the factory. The factory will then deal with the DAL - after and before doing the really interesting things like caching.

Read up on Hibernate / NHibernate.

A good book is also "Scott Ambler's" ancient "Building Object Applications that work".