What use is a Business Logic Layer (BLL)?

Question

In reading up on good practice for database applications I've frequently come across advocates of so-called "business logic layers" and I'm trying to decide if it's best for my project to use one (it's a small personal project). My issue lies in the fact that I can't think of anything for the BLL to do that the DAL can't already handle (executing queries and mapping results to objects), so my BLL just calls the DAL without doing anything itself.

Maybe I'm wrong about exactly what the DAL should be doing too. But regardless, what sorts of functionality should be expected of a BLL in a database management application?

Answer 1

For my smaller applications, my BLL usually starts out as a pass-through to the DAL. I'm okay with that. As I "discover" business rules, the BLL is where I put them. I also end up finding a lot things needed in the BLL as I write my tests. For my own personal apps, I make up the business rules, and the BLL is still where I put them. For me, the BLL is something that grows over time. The longer I've worked on a project, the larger its BLL.

Would I consider combining the BLL and DAL for a small project? I might, except for the fact that I change DAL technologies about as often as I change hairstyles, and I like to have something to isolate my client code from that.

Answer 2

The BLL would handle things that are a part of the business domain, not a part of the database, and not a part of the UI (usually). For example, using the age of a customer to determine if they qualify for a special senior's discount. The DAL shouldn't be doing this, it should simply be retrieving the customer data, and then storing it with the discount data after the BLL has done its work. The DAL should focus more on CRUD. In small applications, the two concerns may overlap.

Answer 3

Andrew,

Business logic layers is what you end up with when you do domain driven development and focus on the core activities of the domain. If you strip out presentation layer (gui, web) and the infrastucture layer (db, network connectivity etc) you've got the core acitivies that are part of your domain, such as depositing money to a bank account. Now if you have modeled your business layer and isolated it from presentation and infrasturcture, you can port it easily to other uses, such as web or mobile devices. It's a clean way to think about development and from what I've seen, it's not taken all that seriously unfortunately.

I'd recommend getting your hands on Eric Evans - Domain Driven Design, which is a good book that justifies focusing development efforts on the domain. Admittedly, it's a bit of a dry read half way through, but it does build up momentum and has some strong convictions as to what developers are doing wrong with today's systems.

Answer 4

Complementing Desolate Planet's answer about Domain Driven Design:

Check out also The Onion Architecture, which is very aligned with the Domain Driven Design concepts.

Notice how the Business Logic "Layer" is the core of the onion, and every infrastructure layer (such as the data access layer) are its external dependencies. This helps with testing, because you should be able to mock every external infrastructure dependency and fully test your domain business logic.

In my opinion: the Business Logic module is where the "pure conceptual solution" lives. The rest are just infrastructure implementation details.

However, some applications might not need this architecture. If your application only performs simple CRUD operations over a database, which is not that rare, your 'business logic' might be in fact practically empty and all you need is a database editing front-end. In that case you probably should be better off focusing on the DAL and UI layers mainly. Do not introduce a layer which doesn't have a clear purpose.

Answer 5

There's nothing that says you HAVE to have a certain number of tiers or layers. It all depends on the complexity of your project. Take a look at many of the MVC sample apps, like nerd dinner or record store.. they all use 2 layers because for applications that have very little processing logic, it just doesn't make sense.

However, even if your app is small it might benefit from abstracting the data layer away from the presentation layer via a third layer that would normally be a business layer. This allows you make changes in a single place, rather than all over your presentation layer.

Suppose you decide to change your ORM from Linq to SQL to Entity Framework (or nhibernate). It will likely be easier to change it in the business layer than in your presentation layer, since presentation tends couple tightly to it's presentation model.

If you understand MVC, that is.. Model View Controller, you can think of your application architecture in similar terms. The Model is analagous to your data layer, the Presentation layer is the View, and Business Layer is the Controller.

Answer 6

The answer to this question is (IMHO): "can I replace my DAL completely and not have to rewrite any of my business logic code"?

Think of it like your presentation layer - its quite common to think of changing the GUI for a different one, a thick desktop GUI gets swapped for a web client, which gets swapped for a iPhone app. Its not so common to think like this for BLL/DAL as they never really get swapped except maybe for something very similar (eg an SQLServer DB replaced with a MySQL one), but if you imagine you had to change your DB to a distributed storage service that was accessed using an API, you might get a clearer idea of where the layers meet.