A 추상 팩토리 또는 부분 클래스를 사용하는 이진 선택

저는 Entity Framework Model First 방식으로 CRUD 응용 프로그램을 작성합니다. 내 응용 프로그램은 UI LAYER와 DAL이 모두 도메인 계층에 종속되어 있고 도메인 계층이 아무 것도 의존하지 않는 방식으로 구성되어 있습니다. Domain 계층은 리포지토리 및 도메인 개체 인터페이스 만 노출합니다. 리포지토리는 DAL에서 구현되고 종속성 삽입을 통해 도메인 계층에 제공됩니다. 모든 리포지토리로서 제 저장소는 getCustomer, deleteCustomer 등과 같은 기능을 노출하지만 DAL에 이러한 기능이 구현되므로 DAL은 도메인 계층의 인터페이스를 준수하는 개체를 만들 수 있어야합니다. 이제 내 바이너리 선택은 어떻게해야할까요? 내가 추상 팩토리를 사용하여 DAL에 삽입하거나 부분적으로 생성 된 엔티티의 정의를 확장하고 도메인 계층에 의해 노출 된 인터페이스를 구현하도록해야합니까?A 추상 팩토리 또는 부분 클래스를 사용하는 이진 선택

출처

2012-11-28 Ibrahim Najjar

누군가 미래에 어느 시점에 귀하의 DAL을 교환하기를 기대하십니까? 왜 DI인가? 당신이 솔루션을 너무 복잡하게 만든 것 같아요. – Heather

@Heather, 실제로 지나치게 복잡하지 않습니다. 올바른 방법으로 설계하는 것입니다. DI는 도구를 사용하기 전에 좋은 원칙을 따르는 것에 관한 것입니다. –

도메인 계층은 리포지토리 및 도메인 개체 인터페이스 만 노출합니다.

이 유형 또는 아키텍처 (hexagonal architecture)에서 도메인 개체에는 인터페이스 만 있으면 안되며 리포지토리 만 있으면 안됩니다. 대신 DAL에 도메인 개체를 직접 만들도록하십시오. 도메인 객체를 인터페이스로 추상화 할 때 얻을 수있는 이점은 없으며, 공장과 같이 불필요한 복잡성 만 있습니다.

또한 Heather가 지적한 것처럼 저장소를 추상화하는 것은 종종 불필요한 복잡성이기도합니다. 구현 전반에 걸쳐 실제로 이식 가능한 저장소 추상화를 만드는 것은 거의 쓸모가 없다. 제 생각에 저장소 추상화의 중심적인 이점은 인터페이스없이 구현할 수있는 캡슐화의 이점입니다. 구현 클래스를 직접 참조하십시오.

출처

2012-11-28 23:53:04 eulerfx

테스트는 어떻게됩니까? 저장소를 설계 할 때 저장소가 필요할 때 항상 인터페이스로 시작합니다. 도메인 객체가 정의 된 후에 프로젝트의 후반부에 repos를 구현합니다. DAL 구현은 내가하는 마지막 일입니다. – MikeSW

솔직히 말하면, 당신이 설명하는 것이 나의 기본 접근 방식입니다. 그러나 저장소 클래스를 본질적으로 스텁으로 지정하여이 작업을 수행 할 수도 있습니다. 또 다른 방법은 조롱 프레임 워크로 저장소 객체를 조롱하는 것입니다. 리포지토리 인터페이스는 리포지토리에 대한 계약을 정의하기 때문에 조직적 관점에서 가져도 좋습니다. 그러나 때로는 테스트 용 인터페이스를 만드는 것이 불필요하다고 생각합니다. – eulerfx

나는 저장소 부분을 제외하고 말한 대부분의 내용에 동의한다고 말해야합니다. 그래서 나는 대답을 승인한다. –

A 추상 팩토리 또는 부분 클래스를 사용하는 이진 선택

답변

관련 문제