Question

So I have a DAO, DTO, and BO. The following code is the result:

// Instantiate a new user repository.
UserRepository rep = new UserRepository();

// Retrieve user by ID (returns DTO) and convert to business object.
User user = rep.GetById(32).ToBusiness<User>();

// Perform business logic.
user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

// Convert business object back to a DTO to save to the database.
rep.Save(user.ToDataTransfer<Data.DTO.User>());

So I am trying to separate concerns, but I want to get rid of the “converts” in this code. The “converts” are actually located in the business logic layer (DTO layer knows nothing of the business logic layer) as an extension object. The DTO itself obviously only stores data and has no business logic what-so-ever. The UserRepository calls the DAO and at the end of GetById uses AutoMapper to map from the DAO to DTO. The “converts” (ToBusiness and ToDataTransfer) do exactly as they say.

A colleague of mine thought I may have to have a Business Repository, but thought it might be a bit clunky. Any thoughts?

Answer 1

I resolved this by creating a Business Service layer. This way I can access functionality through the Business Service layer which in turn uses the Repositories which query the DAL and returns DTOs. The DTOs serve their purpose by being populated by the DAL and help transfer the data to the business layer (converted to business objects).

So the diagram is as follows:

DAL -> Repository (returns DTO) -> Service (returns BO)

It works very well and I am able to put business logic in the Service layer which abstracts it from the Repository itself. Sample code:

// UserService uses UserRepository internally + any additional business logic.
var service = new UserService();
var user = service.GetById(32);

user.ResetPassword();
user.OtherBusinessLogic("test");
user.FirstName = "Bob";

service.Save(user);