正确的n层应用程序引用方法

Question

I am a bit new to n-layer architecture and learning it by implementing a simple console app.

I have 3 projects :

DAL with Domain entities and DbContext class. BLL with Repository class.
Console Application just to run it.

As all my Entities defined in DAL, BLL layer has reference to DAL and looks like:

public class DefaultRepository
{
    private DefaultDbContext _repository;

    private void SaveChanges()
    {
        try
        {
            _repository.SaveChanges();
        }
        catch (Exception e)
        {
            Console.WriteLine("Exception were caught");
            Console.WriteLine(e.Message);
        }
    }
    public void AddPatient(Patient patient)
    {
        _repository.Patients.Add(patient);
        SaveChanges();
    }

    public Patient GetPatientById(int id)
        => _repository.Patients.Find(id) ?? null;

    public void AddVisit(int patientId, Visit visit)
    {
        GetPatientById(patientId)?.Visits.Add(visit);
        SaveChanges();
    }
    public DefaultRepository()
    {
        _repository = new DefaultDbContext();
    }
}

The obvious problem is that I cannot use repository in my console application project because console application has no reference to DAL level. The following code occurs compile-time exception.

DefaultRepository repository = new DefaultRepository();
repository.AddPatient(new Patient());

Of course, I can solve it just by adding reference to DAL in ConsoleApplication project. However, I understand, that absolutely destroy the n-layer conception. So, how should I manage this problem? I googled something about using auto-mappers...

Answer 1

Here I'm not directly giving solution to your use case.But I would like to give right path to implement sophisticated NLayer Architecture application.

What is NLayer Architecture

Layering of an application's codebase is a widely accepted technique to help reduce complexity and improve code reusability. To achieve layered architecture, we can follows the principles of Domain Driven Design . In Domain Driven Design there are four fundamental layers:

Presentation Layer: Provides an interface to the user. Uses the Application Layer to achieve user interactions.

Application Layer: Mediates between the Presentation and Domain Layers. Orchestrates business objects to perform specific application tasks.

Domain Layer: Includes business objects and their rules. This is heart of the application.

Infrastructure Layer: Provides generic technical capabilities that support higher layers. An example of the Infrastructure Layer can be a Repository implementation used to interact with a database through an ORM framework, or an implementation for an email provider to send emails.

There may be additional layers added as necessary. An example being:

Distributed Services Layer: Used to expose application features to remote clients. There are tools like ASP.NET Web API and WCF that can provide this layer. These are all common layers of a domain-centric architecture. There may be minor differences based on implementation.

Overview of layers and structures are shown below:

Here is a solution with five projects for a simple layered application:

If you would like to learn more about this,I highly recommend to study the below mentioned project.It's free and opensource .

ASP.NET Boilerplate

Answer 2

From wiki ( https://en.wikipedia.org/wiki/Multitier_architecture ):

DAL "Encapsulates the persistence mechanisms and exposes the data".

Patient class is not a part of DAL but is the data that DAL exposes to upper level.

I think there are 2 possible points of view:

1. DefaultRepository class should be not in BLL but in DAL. Your code in Console should be in BLL
2. DefaultRepository is a BLL and EntityFramework serves as a DAL.

I any case, your entity "Student" is just a piece of data that can be shared.

If you take more specific pattern like MVC: V (View) and C (Controller) knows about M (Model).

To sum up, you can:

1. create a 4th project that will be shared by all projects and will contain your entities (or interfaces for these entities).
2. Don't bother and add link from Console to DAL. The most important that DAL doesn't have links to BLL and console.