4

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?

e4rthdog
  • 5,103
  • 4
  • 40
  • 89

3 Answers3

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.

Pablo Romeo
  • 11,298
  • 2
  • 30
  • 58
  • If i want to check on ORM for a very small app, can i have traditional hand coded (oledb connection,readers e.t.c) methods alongside with ORM ones, all in one DAL dll? – e4rthdog Dec 08 '12 at 19:56
  • @e4rthdog You could, although it might get really messy, really fast. Why would you need to handle connections or readers manually? – rae1 Dec 08 '12 at 19:58
  • Cause i have something ready already and need to finish it...But i guess that when i start, i will understand that doing it in one way is better....thanks – e4rthdog Dec 08 '12 at 20:02
  • You could, I'm just not sure how much you would gain from that. ORMs have very good performance now-a-days. Just beware that the ORM will manage its database connections, and if you will be doing things manually you need to consider how that affects the ongoing transactions and that kind of thing. – Pablo Romeo Dec 08 '12 at 20:02
2

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.

rae1
  • 6,066
  • 4
  • 27
  • 48
  • I feel for the opinion that its good to make early separation even if the BL does nothing else but just give results and take requests. I do believe that over time i will ask for more. So saying that business decisions (like islotvalid) should go to BL and get belong to DAL is rather ok , yes? – e4rthdog Dec 08 '12 at 19:53
  • Yes, you could have a very simple `GetRecord(int id)` method, then return `bool` based on the `IsValid` property. Then if you need to check another table to check whether `Record` is valid or not you don't have to modify the existing DAL. – rae1 Dec 08 '12 at 19:57
1

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.

Murtuza Kabul
  • 6,438
  • 6
  • 27
  • 34