Pulling out business logic from the data access layer

Question

We are writing some support applications (rather small) to our ERP system.

Thus until now I am feeling that I am using the Data Access Layer for 2 roles: the business layer AND the data access one.

I am having trouble deciding what I have to move to a separate layer and if I need to. I have read somewhere that knowing when to make layer separation is wisdom and knowing the patterns is just knowledge. I have neither in adequate amounts.

So I need some help to determine what is what.

My current DAL deals with fetching the data and applying basic logic on them. For example there are methods like

GetProductAvailabilitybyItem

GetProductAvailabilitybyLot

etc.

If I needed to separate them what I would have to do?

One other matter that is in my head is that in order to normalize my DAL and make it return different entities every time (through one general get method) I would have to use DataTable as return type. Currently I am using things like List<PalletRecord> as return types.

I feel that my apps are so small that its hard (and maybe useless) to discriminate these 2 layers.

My basic need is to build something that can be consumed by multiple front-ends (web pages, WinForms, WPF, and so on).

Additional Example:

Lets talk some barcode. I need to check if a fetched lot record is valid or not. I am fetching the record in DAL and produce a method returning bool in business layer?

Then i can call the bool method from whatever presentation in order to check if a textbox contains a valid lot?

Is this the logic extremely simplified?

Answer 1

Based on your description, you should definitely separate both layers right now, when the application is still small. You might feel a BL is useless when you're just accessing and displaying data, but with time you'll find the need to modify, transform, or manipulate the data, like coordinate object creation from different tables, or update different tables in a single action from the user.

The example you provided helps to support this idea, although is quite simplified.

Pablo's answer does offer some good design ideas too: you should definitely use an ORM to simplify your DAL and keep it very thin. I've found NHibernate and Fluent make a very good job on this. You can use the BL to coordinate access using Data Access Objects.

Answer 2

Given that you are dealing with very small applications, why not just have an ORM provide all data-access for you and just worry about the business layer?

That way you don't have to worry about dealing with DataTable's, mapping data to objects and all that. Much faster development, and you would reduce the size of the codebase.

For example, NHibernate or Microsoft's Entity Framework

Now, if you will be providing data to external consumers (you are implementing a service), you may want to create a separate set of DTOs that go through the wire, instead of trying to send your actual model entities.

Answer 3

I am not a big fan of nTire architecture and have some good reasons for it.

Main objective for such an architecture are

• Ability to work with different underlying database separation of
• context - i.e. application design and business logic Uniformity and
• confirmation of best patterns and practices.

However, while doing so, you also make some sacrifices such as give up provider specific optimizations etc.

My advise is, you can go with two layer architecture,i.e. Data access and business logic layer and GUI or presentation layer. It will still allow you to have a common code for different platforms and at the same time will save you from spaghetti code.