0

my team and I are refactoring our application into a layered application. The app is a windows app that is organized with a UI, Service Layer(SL), Business Layer(BLL) and a Data Access Layer(DAL). Our goal is to keep the Application Logic in the Service Layer, keep the Domain Logic in the Business Layer and communicate between the Service Layer and the UI with DTOs. With that said, my question relates to UI specific data that is stored in the database.

For example (A screen that has 5 phone numbers where the user gets to select the position{1,2,3,4 or 5} that those phone numbers show up on the screen). In my Domain model, I have an entitiy called Phone

public class phone{
 string name;
 string number;
 string extension;
 etc...
}

In the Service Layer I have a DTO name phoneDTO that looks like this

public class phoneDTO{
     string name;
     string number;
     string extension;
     int position;
     etc...
}

Typically, i pass the DTO to the service layer and let the service layer create the objects from the domain model and then call the appropriate DAL mappers.

Question: When persisting the UI related info, what's the best practice for doing so? In my situation the DAL does not have a reference to the DTOs, It does have a reference to the Domain Model.

Michael Wilson
  • 1,207
  • 2
  • 12
  • 16

1 Answers1

1

You could go for the repository pattern (just google it) to persist you entity on the database but in this case this layer should knonw the entity model to persist them

Have a look at:

Repository Pattern vs DAL

For the DTO I think you should have a class/layer that is in charge to build up the objects on both the side: DTO to entityMode and vice versa. The service layer shouldn't know how create the objects but is shold delegate it to another layer (assembler)

UI, Service Layer(SL),// Assembler //Business Layer(BLL) --//**Repository(DAL)

Community
  • 1
  • 1
Massimiliano Peluso
  • 26,379
  • 6
  • 61
  • 70