At what point does data access\manipulation logic becomes business logic?

Question

Consider a service which updates PersonDetail tables in database. I am Using EF which maps the table to this Entity. When a record is updated, it is not actually updated but a new record is created and old one is made history by setting HistoryCode to 0

Class PersonDetail
{
  int age;
  Date birthDate;
  DateTime effectiveDate;
  int sequenceNumber; //An incremental number.
  int HistoryCode; //0 represents history record and 1 current record
}

Now we have a service that updates the person details

if(newPersonDetail.effectiveDate < currentPersonDetails.effectiveDate)
{
  //update sequence number of currentPersonDetails by 1
  //insert a new Person Details record and assign its sequenceNumber as the sequence number    
  //of currentPersonDetails and HistoryCode as 0 to represent this is an history record
}
else
{
   //Make the currentPersonDetails HistoryCode to 0 from 1
   //Insert a newPersonDetail with sequence number incremented by 1 and HistoryCode set to 0
}

Logic? I am trying to move the data-access logic out of service layer to repository layer but not able to clearly figure out what part of this is considered as business logic and what is considered as Data Access logic.

Answer 1

The PersonDetail class is part of the data access. The service that updates PersonDetail is business logic. Note that, if you don't actually need this separation (i.e. you won't need to transplant the service layer to some other program, independently of the data access), it may not matter (you're coupled to the data layer anyway, due to the presence of the POCO's).

Answer 2

Although it's not a very satisfactory answer, pretty much as soon as you introduce a condition (if, switch, etc.) into your data layer code, you're technically mingling business logic and data access.

The reason it's not very satisfying is that this implies that data access code is pretty dumb -- it handles C.R.U.D. behaviors only. That's why ORM emerged -- it took that brain dead C.R.U.D. stuff off our plates.

So, now, you have to clarify what you mean by "data access" layer. A lot of times systems will be somewhat sophisticated and they'll have something called "a data access layer" that's really a combination of data access and very fundamental business logic. For example, it would make sure that you can't commit a "car" to a database without "wheels". Technically that's business logic, but it's so low-level, that it goes along with the data access layer code (often implemented on ORM).

Answer 3

When dealing with the data access layer code, you can think of the following:

• Think of a persister, something that does operations on the data in the underlying persistence layer, such as save, delete, and update operations.

• POJOs that represent the records in the tables are part of the DAL.

• Every thing that depends on and queries that layer directly in order to use the persisted objects in operations can be classified as BL.

• This should be a one way relation of course, BLL layer should depend on DAL and not the opposite.

Now the second code snippet you provided

if(newPersonDetail.effectiveDate < currentPersonDetails.effectiveDate)
{
  //update sequence number of currentPersonDetails by 1
  //insert a new Person Details record and assign its sequenceNumber as the sequence number    
  //of currentPersonDetails and HistoryCode as 0 to represent this is an history record
}
else
{
   //Make the currentPersonDetails HistoryCode to 0 from 1
   //Insert a newPersonDetail with sequence number incremented by 1 and HistoryCode set to 0
}

can be classified as BL if its true in some cases, but can be pushed to the DAL in case this is true whenever you are updating a record.

In some other cases, BL deals directly with the persistence layer for performance reasons, but this depends on what the application does.

Answer 4

Your question cannot be answered in general, but your example shows one thing : difference between business logic or requirement and implementation of that business logic.

In your example, but business requirement might be "Always keep history of changes to all Personal details." Just because it is implemented as flag inside table and not separate table or some other way is implementation detail. Your business analyst doesn't need to know how this history tracking is implemented. So the code in your case can be described as "manipulation logic, that implements a business requirement".