UnitOfWork 및 관심사 분리?

Question

내 MVC 응용 프로그램에서 UnitOfWork/Service Layer/Repository/EF4 승/POCO 디자인을 사용하고 있습니다.

지금까지 나는이 있습니다

1) MVC 웹 응용 프로그램 (Project.dll)
2) 서비스 레이어 (Project.Data.Services.dll)
3) 저장소 층 (Project.Data. Repositories.dll)
4) 포항 강판 (Project.Data.Domain.dll)
5) EF4/컨텍스트 계층 (Project.Data.dll)

각 층은 단지 아래의 층과 상기 참조 Project.Data .Domain (POCO 클래스).

현재 Project.Data.dll에 UnitOfWork Interface/Base가 있습니다.하지만 이제는 모든 레이어에서이를 참조해야합니다. 그게 나쁜 디자인인가요? 그렇다면 어디에 살 것인가?

Answer 1

의견입니다.

도메인 개체는 비즈니스의 일부입니다. 컨텍스트 및 리포지토리와 동일합니다.

실제로 OR/M은 관계형 데이터베이스 나 다른 종류의 저장소에 대한 추상화이므로 개체 지향 저장소로 작동 할 수 있습니다.

OR/M은 최신 소프트웨어 솔루션에서 데이터 레이어를 버립니다.

리포지토리, 도메인 컨텍스트, 도메인 개체는 비즈니스 계층의 일부입니다.

작업 단위는 소프트웨어 디자인 패턴이며 데이터베이스 또는 데이터 계층에 대한 작업뿐만 아니라 네트워크 트랜잭션과 같은 더 많은 작업을 관리 할 수 ​​있습니다. 나는 이것이 "YourCompany.YourProject.Patterns.UnitOfWork"또는 이와 비슷한 어떤 네임 스페이스에 포함되어야한다고 제안합니다.

서비스는 데이터와 아무 관련이 없습니다. "YourCompany.YourProject.Services"네임 스페이스를 제안하고 싶습니다.

다른 점은 POCO가 DTO로도 작동하는 것입니다. 레이어 및/또는 계층을 통해 데이터를 전달하는 경우에도 모든 곳에서 사용하기 때문입니다. 이것은 알몸 개체 구현이나 그와 비슷한 것일 수 있지만 도메인 개체를 속성, 정보, 동작 또는 OR/M 프록시를 사용하여 숨겨진 구성원을 포함 할 수 있으므로 DTO로 도메인 개체를 사용한다는 사실에주의해야합니다. 객체의 가중치 - 메모리 사용에 영향을줍니다.

마지막 단락을 살펴보면 비즈니스 맨 위에있는 모든 계층에서 DTO를 사용하도록 제안하므로 서비스 소비자가 제대로 작동해야하는 특정 속성 범위의 DTO가 반환됩니다.

DTO, 패턴의 구현과 솔루션의 모든 프로젝트에서 공유되는 이러한 것들은 "YourProject.Shared"라는 프로젝트에 있어야하며이 어셈블리는 레이어를 참조하면 안됩니다. 즉, 레이어 중립적이어야하며, 그래서 어디서나 그것을 참조하는 것은 쓸데없는 의존성을 갖지 않습니다.

글쎄, 내 생각은 내 프로젝트에서 일하는 방식이다.

Answer 2

의존성 주입을 사용하는 것이 좋습니다. 이 위대한 소식을 볼 수도 있습니다. http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

Answer 3

다른 레이어가 데이터 프로젝트를 참조하지 않게하려면 IUnitOfWork을 별도의 프로젝트로 분리하고 일부 반전 제어 컨테이너와 함께 종속성 삽입을 사용해야합니다.

Answer 4

https://github.com/sharparchitecture/Sharp-Architecture을 보시오. 귀하의 것과 같이 계층화 된 Northwind 예제가 있습니다. UnitOfWork 구현을 볼 수 있습니다.