n 계층 비즈니스/서비스 계층 설계

Question

저는 우리의 n 계층 아키텍처를 재평가하려고 노력하고 있으며 여러분의 경험을 토대로 몇 가지 제안을하고 싶습니다. 여기에 전형적인 .NET n-layer (때로는 n-tier) 디자인이 있습니다.

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

DATAACCESS는 일반적으로 Entity Framework 4 및 Repository 클래스로 구성되어 있습니다. 나는 테이블에 대한 저장소를 피하기 위해 Aggregate Root 개념을 따르려고 시도하는데, 내 경험으로 말한 것보다 쉽다. 나는 저장소와 테이블간에 ~ 70 % 일치하는 경향이 있습니다.

모델은 대개 내 Entity Framework 4 엔티티로 구성되며, 자체 추적 EF 요소를 사용하고 있습니다.

비즈니스는 내가 가장 힘들어하는 것입니다. 보통 Repository에 대해 Manager 클래스가 있습니다. 이 클래스에는 .Add()와 같은 메소드가 포함되어 repository.Add()로 전달하기 전에 비즈니스 유효성 검사를 수행합니다.

서비스는 일반적으로 웹 서비스 기반 솔루션을 만들기 위해 실제로 구현할 경우에만 구현할 것입니다. 이 계층은 DTO와 엔터티 간의 요청/응답 마샬링을 담당합니다. 가장 중요한 것은 coarse grained 인터페이스를 제공하는 것입니다. 예를 들어 AccountManager.ValidateCash(), OrderManager.SubmitOrder()를 포함 할 수 있습니다 비즈니스 트랜잭션에 대해 정말 facade 인 TradingService.SubmitTrade은() 등

는
내 비즈니스 계층은 매우 실체 관심사 실제로는 엔티티와 리포지토리 간의 접착제이며 유효성 검사가 필요합니다. 서비스 레이어가 저장소에 대한 참조를 보유하고있는 많은 디자인을 보았습니다 (본질적으로 "비즈니스 계층"생략). 본질적으로 그것은 비즈니스 계층과 동일한 목적을 수행하지만 유효성 검사를 수행하지만 책임 (및 명명)은 상위 수준의보다 거친 비즈니스 트랜잭션입니다. 위의 예제를 사용하면 TradingService.submitTrade()가 비즈니스 관리자 클래스에 위임하지 않고 자체 리포지토리를 쿼리하고 모든 유효성 검사 등을 수행합니다.

나는 비즈니스를 재사용 할 수 있다는 의미에서 내 디자인을 좋아합니다. 계층 적 메서드를 여러 서비스 호출에서 사용하지만 모든 저장소에 대해 일치하는 비즈니스 계층 관리자가있어서 추가 작업을 많이한다는 사실을 싫어합니다. 솔루션은 비즈니스 계층 수준에서 다른 유형의 그룹화 일 수 있습니까? 예를 들어 ContactManager와 같은 논리적 관리자 클래스에 PhoneManager 및 EmailManager와 같은 개별 Manager 클래스 (전화 엔터티 및 전자 메일 엔터티가 있음)를 결합합니다 ("연락처"엔터티 형식이 없음). ContactManager.GetPhones() 및 ContactManager.GetEmail() 등의 메서드를 사용합니다.

나는 서비스 계층, 비즈니스 계층 또는 둘 다 보유 여부에 관계없이 다른 구성 및 책임 위임 방법에 대해 궁금합니다. ORM 컨텍스트 참조 등을 보유하고있는 것

Answer 1

나는 당신의 관심사가 끝날 때까지 대략적으로 설명한 것을하고, 비즈니스 계층 그룹에서는 비즈니스 관점에서보다 논리적 인 의미를 가진 관리자를 사용하는 경향이 있습니다.

예를 들어 Contacts를 사용하면 PhoneManager 나 EmailManager가 없을 것입니다. "ContactsManager"는 나에게 더욱 유용한 그룹이며, 다루는 관리자가 적을 때만 똑같은 작업을 수행합니다. 비즈니스 관점에서 보면 전화 번호와 이메일은 연락처의 작은 부분 일뿐입니다. 그들 자신의 테이블과 엔티티를 가지고 있다고해서 그들이 자신의 매니저가 필요하다는 것을 의미하지는 않습니다. 그렇다고 재사용 할 수 없다는 의미는 아닙니다.여러 곳에서 이메일 주소로 작업해야하는 경우 ContactsManager에서 관련 방법을 사용할 수 있습니다.

우리는 우리 환경에서 데이터베이스/엔티티 계층, 그 다음 서버에 앉아 비즈니스 규칙 및 비즈니스 논리를 처리하는 비즈니스 계층을 갖는 경향이 있습니다. 해당 비즈니스 계층은 WCF를 통해 클라이언트에 대한 서비스로 노출됩니다 (또는 최소한 클라이언트와 관련있는 항목이 있음).

당신이 뭘하고 싶은지 이미 알고있는 것처럼 들리므로, 프로토 타이핑 작업을 조금 해보고 어떻게 작동하는지 보시기 바랍니다. :)