Thread: Approaching THB
View Single Post
  #9 (permalink)  
Old September 24th, 2007, 04:14 AM
ViagraFalls ViagraFalls is offline
Friend of Wrox
Join Date: Sep 2003
Location: Copenhagen, , Denmark.
Posts: 143
Thanks: 0
Thanked 1 Time in 1 Post

philthy - Just to make sure we're talking about the same thing here. When you use the term "provider model", you mean the Data Access Layer?

If so, the reason this setup is chosen lots of times is that lots of web developers cannot be entirely sure which underlying database platform their clients use. Some use SQLServer, some will use Oracle, yet others run on Progress, and some use mySQL (or any other flavour).

By introducing a seperate provider model, the developer can ensure that the code to access and execute SQL stataements (or stored procedures) against the underlying database can be optimized per database platform. There might be other ways to index, or there might be differences in the database platform's implementation of the ANSI SQL language.

Thus, after you create the database providers, the rest of your code does not have to know what it is running against. All of that has already been handled. This means the Data Access layer can then focus on just retrieving and storing the data.

In turn, the Business Logic Layer, also doesn't need to know where the data comes from. It just accesses the DAL, pulls out the data, and then can ensure the data matches all the business rules in place.

The UI is just that; a user interface. It knows it gets proper data, and it presents it.

By seperating things into layers like this, when a business rule changes, there's a good chance there's only one spot (the BLL) where you need to change code. All the other layers remain the same. This means much less administrative overhead, and reduces the chance of breaking your existing code.

Should you want some more info, don't shun to ask :)