Design – Is Business layer required when all it does it call data layer function

Architectureasp.netdesign

I have inherited ASP.Net Web form code. Here the business layer is just calling the function of data access layer. For example

public string GetCountry(int countryCode)
{
  MyDLSrv obj = new MyDLSrv();
  return obj.GetCountry(countryCode);
}

In short, if you see method signature of function in DAL and BL, it is more or less the same. This is made-up example and is not perfect i.e. checks/validation/try-catch. But the question is what value this BL is adding other than DL not directly accessible in presentation layer? Is it good practice? If not, what would be the correct way?

Best Answer

Is Business layer required when all it does it call data layer function?

If by reading a business layer you mean retrieving objects which are used when writing to a data store (ie. objects which contain validation, etc.) and transforming and outputting these objects to the user then the answer is a simple no.

A few years ago a new approach to building systems has been published by Greg Young, called CQRS (Command Query Responsibility Segregation).

In layman's terms, CQRS (Command - writes, Query - reads) is nothing but an approach to have at least two (or more) objects when interacting with the data store - one for writes and one for reads. When writing to a data store you would have a complex validation that the command that has been issued is valid and not against your system's state. On the other hand, if all commands go through a strict validation then you can trust your system it always contains valid data and as such queries (reads) can simply pull data out of the data store using simple DTOs and output it to the users directly (without the hassle of transforming the data between a business layer and a view).

When combined with event sourcing, CQRS takes the read layer to another level - by querying a completely different data store than the one to which the writes are being made. The writes may be made to a 3NF normalized database and during each write a denormalized (cached) version of an entity is published to a denormalized data store. Queries then query the denormalized data store, which increases performance. Taking this into consideration it's clear queires (reads) cannot go through business layer at all, because the data store used by queries is completely different.

If all you're doing is querying the data, circumventing the business layer is OK.

Related Topic