使用自上而下的体系结构，我的业务层无法访问我的数据访问层，这是怎么回事？

Question

Using Asp.Net MVC I wanted a top down approach. I started using a top down approach but now it seems like it's an onion approach because my repository interfaces in the data access layer need to reference my model layer so it understands the objects it's returning. So now I'm referencing up and not down.

Now I have a method (LoadAllAppointmentsInDateRange) inside a model (DiaryEvent) in the business layer that needs to call the repository in the data access layer below, but it can't because there would be circular references. How did I screw this architecture up and how can I fix it? Should I create another layer (service layer) that takes care of this and puts the method (LoadAllAppointmentsInDateRange) inside it or should I move my interfaces?

Here is what I have and what I want to do on a simplified level.

Controller (top layer) -

public JsonResult GetDiaryEvents(double start, double end)
    {
        var apptListForDate = DiaryEvent.LoadAllAppointmentsInDateRange(start, end);
        //do some other stuff
        return Json(rows, JsonRequestBehavior.AllowGet);
    }

Business layer (middle layer) -

public class DiaryEvent
{

    public int ID;
    //other memebers here


    public static List<DiaryEvent> LoadAllAppointmentsInDateRange(double start, double end)
    {
        // logic here

        // want to access the repo here, but can't because data access layer is referencing this layer (business layer)
        IYogaSpaceEventRepository eventRepository = new YogaSpaceEventRepository();
        IQueryable<YogaSpaceEvents> events = eventRepository.FindEvents(startTime, endTime);


        //do some processing of the returned data
        return result;
    }
}

Access layer (bottom layer) - it references the business layer.

public class YogaSpaceEventRepository : IYogaSpaceEventRepository
{
    YogaContext context = new YogaContext();

    public IQueryable<YogaSpaceEvent> FindEvents(DateTime start, DateTime end)
    {
        var rslt = context.YogaSpaceEvents.Where(s => s.DateTimeScheduled >= start 
            && DbFunctions.AddMinutes(s.DateTimeScheduled, s.AppointmentLength) <= end);

        return rslt;
    }  

    public void Dispose()
    {
        context.Dispose();
    }
}

public interface IYogaSpaceEventRepository : IDisposable
{
    // here my repo (data access layer) is referencing my business layer to return YogaSpaceEvent
    IQueryable<YogaSpaceEvent> FindEvents(DateTime start, DateTime end); 
}

Answer 1

Here's how you should structure your project:

In you Business Logic Layer store your business entities and repository interfaces as follows:

public class YogaSpaceEvent
{
    // Function and Data Members
}

public interface IYogaSpaceEventRepository
{
    IQueryable<YogaSpaceEvent> FindEvents(DateTime start, DateTime end);
}

public class DiaryEvent
{
    private IYogaSpaceEventRepository _repository;

    public DiaryEvent(IYogaSpaceEventRepository repository)
    {
        this._respository = repository;
    }

    public static List<DiaryEvent> LoadAllAppointmentsInDateRange(double start, double end)
    {
        // Call appropriate method on _repository
    }
}

In your Data Access Layer (DAL), Add a reference to your BLL and implement the YogaSpaceEventRepository repository:

public class YogaSpaceEventRepository : IYogaSpaceEventRepository
{
    public IQueryable<YogaSpaceEvent> FindEvents(DateTime start, DateTime end)
    {
        // Retrieve Data from Database
    }
}

In your presentation Layer (MVC Controller) you first have to add a reference to your BLL and DAL, and then create an DiaryEvent object injecting an instance of the YogaSpaceEventRepository repository, like so:

public class PresentationLayer
{
    public void Test(double start, double end)
    {
        DiaryEvent diaryEvent = new DiaryEvent(new YogaSpaceEventRepository());
        var apptListForDate = DiaryEvent.LoadAllAppointmentsInDateRange(start, end);
    }

}

Answer 2

If what you call the Business layer is equivalent to the Domain Layer in DDD, it shouldn't know about data access.

Delegate data access to an Application layer that knows the current application execution state, and keep your core domain devoid of persistence details. This way it is nicely decoupled -- you can put whatever persistence you wish and any number of applicative systems around it without changing the core business rules.