Do I need to Separate Business Objects and Business Logic? Asp.net MVC with Repository Pattern in C#

Question

I'm having trouble finding an answer to this. Basically, right now I have these layers:

• Data Access Layer (where my repositories are). It has Namespace Hello.Data
• Business Layer (where my business objects are). It has Namespace Hello.Business

My repositories will return business objects. For example, GetCustomer will return Customer.

However, in my business layer, I also want to add logic that will use the repository to add/update/delete records, so I can reuse those methods in my MVC controllers. This doesn't work though, since I can't have my Data Access Layer reference my Business Layer and also have my Business Layer reference my Data Access Layer. (It creates a circular reference that is not allowed).

What do you guys think is the best solution? Should I put my Business Logic into it's own project?

So instead of:

Hello.Data
Hello.Business

I'll have:

Hello.Data
Hello.Business
Hello.BusinessLogic

Or am I thinking about this all wrong? Thanks!

Answer 1

Why would you separate business logic from business models? The logic should be in the models.

The business logic layer shouldn't have to reference anything, aside from maybe small common utility libraries. Basically, it should have no dependencies on infrastructure concerns (like application technologies, database technologies, etc.). It should contain just business logic.

All other layers should reference the business logic layer.

This doesn't work though, since I can't have my Data Access Layer reference my Business Layer and also have my Business Layer reference my Data Access Layer.

Correct! The mistake in this design is that the business logic layer references the data access layer at all . It shouldn't.

It should , however, contain interfaces for data access (and other infrastructure concerns) which are implemented by the data access layer. The business logic layer only needs to know about the interfaces, it doesn't know or care what implements those interfaces.

A dependency injection container would then be used to connect implementations to interfaces.

• The application layer references the dependency injection layer to initialize it and pass the container (which itself implements a generic business logic interface) to the business logic layer.
• The dependency injection layer references the business logic layer to know about the interfaces and references the data access (and other infrastructure) layer to know about the implementations.
• The data access (and other infrastructure) layer references the business logic layer to know about the interfaces to implement.
• The business logic layer doesn't reference anything. It requires a configured dependency injection container and uses that container to get implementations for interfaces.