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?

  • Sounds like efficiency vs flexibility/code reuse dilemma.
    – Job
    Commented Feb 4, 2011 at 21:57
  • @Job - Yeah, sort of, especially since it's a small app with little chance of code reuse (yet). But it's also partly trying to use the best practice possible.
    – Andrew
    Commented Feb 4, 2011 at 21:58
  • I upvoted everyone because they are all great answers; unfortunately I can only accept one.
    – Andrew
    Commented Feb 5, 2011 at 5:12

6 Answers 6


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.

  • 2
    I haven't changed my hairstyle in 20 years. I'd hate to change my DAL technology as often as I change hairstyles. Commented Feb 4, 2011 at 21:53
  • 4
    Some people only update their DAL every 20 years too!
    – Marcie
    Commented Feb 4, 2011 at 21:54
  • 4
    Good answer. It's common for small projects to really not have very much to put in the BLL. It's also common for small projects to grow bigger, and if you didn't have a least a shell of a BLL in place, the growing amount of logic is either going to accumulate in the presentation layer or the DAL, neither of which is particularly desirable. Commented Feb 6, 2011 at 6:55

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.

  • Actually, this is part of the problem with trying to isolate "tiers" or "layers" like this. Often times, something has to cross layers because it's better suited in that different layer. A great example is SQL queries that have business logic built into them. Your age calculation, for instance, could be entirely done in the SQL (or the ORM) layer more effeciently. Commented Feb 4, 2011 at 21:44
  • 2
    @Mystere Man More efficiently is subjective. That comment means that you know what is taking place on the front-end. It is very static in nature. Make use of SQL queries to optimize the data for sure but there is a fine line as you begin to tie a UI into the back-end. Commented Feb 4, 2011 at 21:49
  • 1
    @Mystere Man: Indeed it can. And it's often true that things "bleed" through from one layer to another. The real art is in separating them and keeping them separate. I know, it's not always easy... Commented Feb 4, 2011 at 21:50
  • 2
    And boom, premature optimization raises its ugly head! I find it hard to imagine that a simple date comparison is such a bottleneck that it warrants moving a business rule to the DAL. Maintainability should be a goal too, not just speed.
    – TMN
    Commented Feb 8, 2011 at 17:28


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.


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.