Hi,

I am developing a web application. I have read that the best approach to such an application is to use a presentation layer, business logic layer and data access layer.

The presentation layer and data access layer are clear to me. However, I am a little confused about the business logic layer. All the examples I have seen simply call methods in the data access layer to return datasets back to the UI. This just seems like additional overhead without any benefit.

I considered putting validation rules into business logic components, but this is easier to place in the UI using validation controls. What then is the benefit of having a BLL? Are therea any examples that show the BLL doing more than invoke methods in the DLL?

Thanks

 The validation controls only work on the client, which can easily be bypassed. You should always validate in your business entities. I agree the example you have looked at are lacking. Especially if they are using Datasets. you should be using entity classes and genric list, etc.

Look at the Beer House starter kit for a little clue. I am not a fan of the use of the DataSource controls, but nonetheless it is a decent example of the better way to do things.

For software architecture in general, my best advice is the _keep it simple_:

> The presentation layer and data access layer are clear to me. However, I am a little confused about the business logic layer. All the examples I have seen simply call methods in the data access layer to return datasets back to the UI. This just seems like additional overhead without any benefit.

There is no benefit where there is no need! Then, when you have the need, keep following the need!!

> I considered putting validation rules into business logic components, but this is easier to place in the UI using validation controls.

The integrity of the information-data should be guaranteed, at the most fundamental level, by the database itself (relations, rules, constraints, encapsulation, access control, and what-not). Once that is clear, one can more easily see how there is a hierarchy of components up to the presentation layer, as well as how thinking in terms of lighter/service-oriented architectures becomes natural with the database as a self-standing data service component.

HTH,

-LV

akpuk:

The presentation layer and data access layer are clear to me. However, I am a little confused about the business logic layer. All the examples I have seen simply call methods in the data access layer to return datasets back to the UI. This just seems like additional overhead without any benefit.

Business layer contains all the business logic. All processes happen there. DAL is layer for communication with data store (you can abandon one DAL and replace it by another without modifications to other layers). Presentation layer deals purely with user communication.

akpuk:

I considered putting validation rules into business logic components, but this is easier to place in the UI using validation controls. What then is the benefit of having a BLL? Are therea any examples that show the BLL doing more than invoke methods in the DLL?

You can use UI validation controls to make users happier but "evil" users can go around it and post data to server just as they like. You have to always check data that is posted by user on server side. To avoid building validation logic inside your classes you can use validation frameworks (Enterprise Library has one, by example).  

LudovicoVan:

There is no benefit where there is no need! Then, when you have the need, keep following the need!!

I completely agree with LV, if you think your business layer is too "thin", that means you dont have much complex business logic, so you can work with a 2-tier architecture which should work perfectly fine.

In case you do need a business layer, then you have to do the validations in that layer itself because in a truly distributed environment you do not know which layer would connect with your business layer in future and whether it will validate the data before sending it to the BL layer or not.

HTH,

Vivek

 As stated previosly, keeping the arcitecture as simple as required is a good thought process.  There is no need to create some elaborate n-teir logical architecture for a 1 page web app that asks for your zip code and spits out the towns associated with it from the database.

...However with that being said, you could still frame up your application to have the 3 main layers in anticipation that the application may grow and allows you the developer to have an easily scallable design.

For example, 6 months down the road the person that asked you to make that simple page with the zip code entry liked it so much now that want to add GPS location, maps, phone number lookups, social networking tie-ins, regional statistics, graphs with calculations and more.  If the app was designed with the main 3 layers (UI, BL, DAL) from the get-go you will have an easier time implementing the enhancments because the bones of the application will support it.

This is not to say that if you start with a 2-tier design it could not be re-engineered with the 3rd layer for your business logic in the future. A lot of times when designing an app you can anticipate with some degree of certantity if this is always going to be a really small simple functionality app or something that may grow.

Now to your original post about why you may need a business logic layer.  From your original post and my simple zip code example site, you may just need validation at the UI to ensure that only a 5 digit zip code was entered (USA) and no letters or special charachters were entered (via AJAX filter, .js, server side code, whatever).  Now say there was an odd new requirement that stated "Add 10 and subtract 10 in intervals of 1 from the zip code entered to get a total of 20 zip codes, which will represent most of the zip codes from the surrounding areas.  Then using those 20 zip codes look up in the database statisics on population and present it back along with any telephone area codes belonging to those 20 zip codes". 

Now while that may be an odd requirement, it is something more than you want to be decicding at the UI layer, and it requires more decision making and processing than just simply filtering and validating user input.  In this case a Business Logic Layer could be helpful to separate this logic into its own layer to be presented back to the UI ultimately (this is the topic for an entire different conversation, many books have been written on how to design the business logic, and there are a ton of different ways to go about doing it.)

Hopefully this helps clarify your question

 Thanks all - your posts have been most helpful.

Based on the requirements of my application I think it would be worthwhile having a BLL. I have many data maintenance screens with lots of validation rules associated with them.

I have another question regarding the BLL (should I create a new thread?):

I was planning to use the BLL to receive a datatable for each entity and send this to the UI where it can be bound to a GridView. I have read that it is better not to pass a dataset back to the UI, but better to pass a class. Why it this the case? Again, this just seems like additional overhead.

Thanks

akpuk:

(should I create a new thread?

Yes please, close this thread and start a new one :)

akpuk:

(should I create a new thread?):

Like this excerpt when speaking about objects:

"In short, an object should do one thing and do it well."  ...we have done that with this thread; we spoke about the single question you had and did it well    You should start a new thread about your last question because it too can go really in depth about the topic.