design patterns - Do you allow the Web Tier to access the DAL directly?

Question

I'm interested in perceived "best practice", tempered with a little dose of reality here.

In a web application, do you allow your web tier to directly access the DAL, or should it go through a BLL first?

I'm talking specifically of scenarios where there's no "business logic" really involved -- such as a simple query : "Fetch all customers with surname of 'Atwood'". Scenarios where there's any kind of logic absolutely are gonna go through the BLL, so lets call that moo.

While you could encapsulate this method inside a BLL object, it seems to be somewhat pointless when often the signature will be exactly the same as that of the DLL object, and the code probably as simple as a one liner delegating the query off to the DLL.

If you choose the former -- employing a BLL object -- what do you call these objects? (Assuming they do little more than provide a query layer into the DLL). Helpers? QueryProviders?

Thoughts please.

Regards

Marty

Answer 1

I disagree with most the posts here.

I call my data layer in the web tier. If there is nothing in between the WEB/UI tier there is no point creating a layer "just in case." It's pre optimization. It's a waste. I can't recall a time the business layer "saved me." All it did was created more work, duplication and higher maintenance. I spent years subscribing to the Business Layer --> Data Layer passing entities between the layers. I always felt dirty creating pass through methods that did nothing.

After being introduced to Domain Driven Design by Eric Evans, I do what makes sense. If there is nothing in between the UI and the Data Layer then I call the Data Layer in the UI.

To allow for future changes I wrapper all my Data Layer classes in interfaces. In the UI, I reference the interfaces and I use dependency injection to manage the implementation. After making these changes, it was like a breath of fresh air. If I need to inject something in between the data layer and UI, I create a service.

Another thing I did, was to reduce the number of projects. Before I would have a project for the Data Layer, Business Logic, Business Entities and some type of UI Project -- what a pain.

I have two projects: The core project(entities, business logic and data layer) and UI projects (web, web services, etc...)

For more information I recommend looking at these guys:

• Develop with Passion
• Jeffrey Palermo
• David Laribee