Home/ Questions/Q 8968549
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T17:28:12+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0