Circular reference issue in 3-tier architecture C#

Question

I want to build a web application with 3-tier architecture in ASP.NET. But I am getting a problem of circular referencing.

I have 3 layer:

1. Application layer containing UI.
2. Business layer containing all the logic and domain classes.
3. Data layer containing all database interaction methods.

I am using the data layer methods in business layer to perform database operations and in these methods I need to pass domain class object to data layer but it can not be done due to circular referencing.

For example I have a Person domain class containing some properties and methods. Now I want to insert that Person into database. I have a method in Person class, named as InsertPerson(). In this method body, I have to call the function of Data layer to insert into database. But I am not able to pass the whole person object into data layer method as data layer reference is added to business layer and vice-versa is not possible.

So how can I avoid this problem? Please suggest.

Answer 1

Is it possible to split the domain objects from the business logic for manipulating them? So you have classes describing the data, containing relatively primitive operations, and then your business layer is more actions on the data - often using several different classes in one action.

You then end up having four assemblies:

  UI              /
  Business logic  | Domain classes
  Data layer      \

So all three layers use the domain classes as common terminology, effectively.

I've seen this work pretty well - it does mean that your domain classes typically become slightly "dumb", although they can still contain relevant logic around some validation etc for aspects which are independent of other classes.

Of course, there are plenty of alternative approaches :)

Answer 2

Your business logic dll should not have reference to the data access layer. Data access layer should have reference to your business logic dll. Business logic code should define interfaces it wants to talk with in order to access database (or other external to business logic stuff) and other dlls should implement them to provide services for business logic layer.

This is the Dependency Inversion Principle. It says that high level modules should not depend on low level ones. Here business logic is the high level module. Data access dll is just implementation detail from Business logic dll perspective.

To show example

BLL:

public interface IPersonRepository
{
    void SavePerson(Person p);
}
public class PersonServices
{
    PersonServices(IPersonRepository repo)
    {
      //
    }
    public void FirePerson(Person toFire)
    {
        toFire.FireHim();
        repo.SavePerson(toFire);
    }
}

DAL:

public class PersonRepository : IPersonRepository
{
   // ...
}

UI:

var repo = new PersonRepository();
var ps = new PersonService(repo);   // wire by hand or use container

ps.FirePerson(somePerson);

References:

UI -> BLL
   -> DAL

DAL -> BLL

BLL -> nothing!

Answer 3

You'd better use classic DDD: Domain (business logic) should not have any reference to DAL (Infrastructure for persistence) it just declares interfaces that infrastructure has to implement (repositories) than in Application layer you write app services that use domain and the presentation layer uses only application layer (or distributed services if its about distributed app):

Good example of (D)DDD: http://microsoftnlayerapp.codeplex.com/

Answer 4

If you use 3-tiers architecture in your application, you are unable to pass object to data access layer. the ojects can be used in business layer only. The best architecture is domain module if you want to use object in data access layer.