순환 종속성을 피하는 방법 DAL.DbContext.DbSet <BLL.Model>

Question

DbContext가 DAL에있는 경우 DbSets의 제네릭 형식 인수는 BLL 클래스 (도메인 모델) 일 수 없습니다. 이 레이어를 분리하는 가장 좋은 방법은 무엇입니까? DAL의 추가 모델은 무엇입니까? 인터페이스?

Answer 1

일반적으로 도메인 모델은 별도의 레이어로 간주됩니다.
클래식 MVC paradaigm을 살펴 본다면 모델은보기와 컨트롤러에서 모두 사용됩니다.
DAL에서도 사용해야하지 않을 이유는 없습니다.

그러나 모델은 DAL을 참조하지 않습니다. 데이터 저장소에 대한 모든 작업은 컨트롤러에 의해 수행됩니다.

그래서 사물의 일반적인 흐름이
사용자가 View View와 상호 작용 BE- 것이 Model 객체 Controller이 Model 객체의 메소드를 호출을 검색하기 위해 사용하는 Controller Controller에있어서, 상기 DAL를 호출 DAL를 사용하여 (저장합니다) 필요에 따라 답변을 반환하고 View

Answer 2

DDD를 수행하는 경우 리포지토리 (최소한 해당 인터페이스)는 비즈니스/도메인 계층의 일부라고 생각합니다. 리포지토리의 구현은 해당 비즈니스/도메인 계층을 참조해야하는 별도의 어셈블리입니다. 따라서 귀하의 DAL은 귀하의 비즈니스 오브젝트에 대해 알고 있지만 그 반대가 아닙니다. 의존성 삽입을하려면 IRepository 인터페이스에 대해 Repository를 사용하도록 컨테이너를 구성하는 무언가가 DAL 계층에 있어야합니다. 단 위 작업 단위가 필요한 경우 인터페이스는 비즈니스 계층의 일부 여야 할 가능성이 큽니다. 다시 구현은 DAL에 있고 DAL은 DI 컨테이너를 적절하게 구성합니다. 이것은 실제로 리파지토리 패턴에 대해 싫어하는 것 중 하나입니다. 인터페이스의 사용자가 IUnitOfWork를 올바르게 관리 할 필요가 있거나 리포지토리를 감싸는 무언가가 필요하기 때문입니다.

전통적인 n 계층 아키텍처에서는 상황이 조금 다릅니다. 이 경우 비즈니스 계층은 DAL과 대화 할 수 있으며 일반적으로 데이터베이스에 데이터 행을 나타내는 DTO를 갖도록 DAL을 작성했습니다. 비즈니스 계층은 이러한 DTO를 사용하여 비즈니스 객체를 수화합니다 (CSLA.Net과 같은 것을 사용하는 경우 비즈니스 객체는 스스로를 수화하는 방법을 알고 있습니다).

어느 쪽이든 순환 참조로 끝나는 상황이 있어서는 안됩니다.

Answer 3

귀하의 BLL 또는 도메인 계층은 데이터 액세스 기술 세부 사항에 대해 걱정할 필요가 없습니다. BLL은 기술 독립적입니다. Entity 프레임 워크를 계속 사용하려면 POCO 엔티티를 생성하고 별도의 레이어로 이동해야합니다. 이렇게하면 순환 참조를 피할 수 있습니다.