Круговая зависимость .Net Core 2.0 Web Api после перемещения контекста базы данных в библиотеку классов DAL - PullRequest
0 голосов
/ 11 мая 2018

Я создаю веб-интерфейс, который использует службу Microsoft Identity. Чтобы создать более поддерживаемый проект, я решил создать проект DAL (Data Acces Layer), который представляет собой простую библиотеку классов, чтобы сделать мой код более разобщенным.

Я переместил свой dbcontext, который наследуется из IdentityDbContext, в проект DAL. Мой BLL (Buissness Logic Layer) имеет ссылку на мой DAL, поэтому он может вызывать функции в моем DAL, но поскольку мой dbcontext наследуется от IdentityDbContext, мне нужна ссылка в моем BLL на мой DAL, чтобы я мог добавить службу dbcontext при запуске класс, который, конечно, создает круговую зависимость.

так что мои вопросы

  1. Считается ли хорошей практикой переносить контекст вашей базы данных в DAL?
  2. Если так, как я могу решить мою проблему, чтобы мне не требовалась ссылка из моего DAL на мой BLL?

Большое спасибо заранее.

Ответы [ 2 ]

0 голосов
/ 11 мая 2018

Ваш контекст данных принадлежит слою доступа к данным, если вы следуете подходу.Однако, в зависимости от того, как вы реализуете через чистую архитектуру (причудливая терминология для луковой архитектуры) или N-уровневую архитектуру.Эти два подхода предназначены для разделения задач, однако чистая архитектура часто даже более абстрактна и слабо связана, чем типичная архитектура N-уровня.

Основополагающий подход, хотя для ваших зависимостей N-уровня, будет следующим:

Уровень доступа к данным:

  • Уровень домена (простые старые объекты C #)

Уровень обслуживания (необязательно):

  • Уровень доступа к данным
  • Уровень домена

Уровень представления:

  • Сервисный уровень

Однако, если вы включите в среду, такую ​​как Asp.Net Core, вы заметите, что ваше решение опирается на промежуточное ПО.Уровень представления для модуля, контроллера, просмотра всех находится в файле решения.Таким образом, непреднамеренно у вас будет уровень представления для обработки вашего UX, но вам потребуется IServiceCollection, чтобы зарегистрировать эти другие зависимости, создавая слой в соответствии с:

Уровень представления:

  • Уровень доступа к данным
  • Уровень домена
  • Уровень обслуживания

Это решит проблему циклической зависимости, но затем вам придется выбрать подход связывания.Но это самый распространенный и простой пример, который вы часто видите.

Уровень доступа к данным:

public interface ISampleRepository : IDisposable
{
     IEnumerable<SampleModel> GetAllSamples();
}

public class SampleContext : ISampleRepository
{
     public IEnumerable<SampleModel> GetAllSamples()
     {
          // Implementation
     }
}

public interface ISampleFactory
{
     ISampleRepository Create();
}

public class SampleFactory
{
     ISampleRepository Create() => new SampleContext();
}

Уровень обслуживания:

public class SampleService
{
     IEnumerable<SampleModel> RetrieveSamples()
     {
          using(var context = new SampleFactory().Create())
               return context.GetAllSamples();
     }
}

Уровень представления:

public class SampleController
{
     public JsonResult Index() => new JsonResult(new SampleService().RetrieveSamples());
}

Вы можете использовать Dependency Injection или что-то еще, но это базовый подход, который поможет вам показать, как структура предназначена для работы внутри.Ни одно решение не является идеальным, выберите то, что соответствует требованиям вашего приложения, не добавляйте дополнительной сложности, если только оно не решает законную проблему, но, надеюсь, это поможет вам понять.

0 голосов
/ 11 мая 2018
  1. Да, вот где оно принадлежит. Однако то, как вы определяете слой, может варьироваться, что может оставить вас с различными структурами проекта. Я поместил бы контекст в его собственную библиотеку, а затем создал DAL в отдельной библиотеке, и на него можно было бы ссылаться только на библиотеку контекста данных из проекта DAL, а не на другие, но это не связано с рассматриваемой проблемой.
  2. Рефакторинг ваших слоев и API для использования интерфейсов друг друга вместо конкретных классов. Поместите эти интерфейсы в свои собственные библиотеки классов. Обращайтесь к этим библиотекам классов интерфейсов как из уровней, обеспечивающих их реализации, так и из API / уровней, их использующих Удалите ссылки на библиотеки, предоставляющие конкретные реализации самих потребителей. Где бы вы ни связывали зависимости (либо в вашем API, либо в вашей библиотеке инъекций / IOC, если таковая имеется), обращайтесь к библиотекам интерфейса и реализации. До тех пор, пока эти интерфейсы не имеют каких-либо сложных зависимостей и на ваш уровень или API IOC не ссылаются каким-либо странным образом, этого должно быть достаточно для решения ваших проблем циклической зависимости. Если ваши интерфейсы должны ссылаться друг на друга, вам нужно поместить их оба интерфейса в одну и ту же библиотеку или провести дальнейший рефакторинг ваших интерфейсов, чтобы уменьшить эту связь.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...