데이터 계층에서 데이터를 검색하는 리포지토리 (CustomerRepository)가 있습니다. 대부분의 비즈니스 로직은 리포지토리가 수락하거나 반환하는 엔터티 클래스 (Customer)에 있습니다.저장소 패턴 및 비즈니스 논리
그러나 글로벌 엔터티 비즈니스 로직 (모든 고객에게 적용되는)은 어디에 배치합니까?
예를 들어 모든 고객을 특정 사용자에게 돌려 드리고 싶지 않을 수 있습니다. 나는 그 논리를 저장소에 넣고 싶지 않습니다.
나는 Robert Munteanu에 동의합니다.
기본적으로 모델에 내재되어 있지 않은 비즈니스 논리를 중간 계층으로 롤업합니다. 중간 계층은 비즈니스 계층/비즈니스 개체/비즈니스 논리 계층/등이지만 단지 서비스 계층이라고합니다. 웹 서비스 일 필요는 없으며 특정 응용 프로그램 영역의 기능을 집계한다는 점에서 서비스라는 용어를 광범위하게 사용합니다.
기본적으로 리포지토리 참조를 포함하는 CustomerService 클래스가 있습니다. 프리젠 테이션 계층은 서비스 계층 클래스를 참조합니다.
.net을 사용하고 있으며 NerdDinner에서 설명한대로 LINQ to SQL을 리포지토리로 사용하는 것으로 추측 할 수있는 추가 구분이 있습니다.
리포지토리는 일반적으로 IQueryable을 서비스 계층에 반환하므로 서비스 계층 체인이 여러 쿼리를 서로 다른 결과 집합으로 만들 수 있습니다. 그런 다음 서비스는 ToList 또는 다른 유사한 메서드를 사용하여 표현식을 평가하고이를 표현 계층에 반환합니다.
다른 저장소 (BusinessRuleRepository)에 저장하고 CustomerRepository에서 사용하도록하십시오.
또는
비즈니스 로직은 사용자가이 공장으로 Facade 패턴을 사용할 수 있습니다 볼 수있는 결과를 제한하는 경우. 이 경우 CustomerRepository 및 LimitedCustomerRepository (CustomerRepository를 캡슐화 할 수 있음)를 처리하는 ICustomerRepository와 사용자에 대한 적절한 ICustomerRepository를 반환하는 CustomerRepositoryFactory가 있어야합니다.
이러한 유형의 기능을 서비스 계층으로 분리하는 것이 좋습니다.
저는 최근에 이력 데이터를 사용하여 많은 엔티티와 복잡한 예측을 수행하는 시스템을 구축했습니다. 각 엔티티에 대한 저장소에 모든 데이터 액세스 비트 배치. 복잡한 예측 논리는 서비스 계층에 보관되어 필요에 따라 저장소 개체를 전달했습니다.
보너스는 단순히 웹 API 계층을 생성하여 모든 예측 로직을 외부 시스템에 노출시키는 쉬운 방법이 있다는 것이 었습니다.
Rob Conery의 MVC Storefront는 저를 저장소 패턴으로 바꾸었지만 불행히도 비디오에서 그 결정을 실제로 설명하지 않고 서비스 계층을 리팩토링했습니다. 그래서 나는 그것이 아마도 최선의 방법이 아니었을 까 걱정했습니다. –
비슷한 문제가 발생했습니다. 이것이 최고의 아키텍처입니까? 나는 공장이있는 계층의 계약에 대한 인터페이스에 대해 걱정하는 것을 멈추고, 단지 그것을 작동시키는 것에 집중했다. 너무 자주 사람들이 솔루션을 과도하게 설계하는 방식이라고 생각합니다. 코드베이스의 순간을 구축하려는 목적은 계층과 계층의 고유 한 강점과 완벽성에 대한 찬사입니까? 리파지토리에 데이터 항목을 보관하고 비즈니스 서비스에 "비즈니스 로직"을, 그리고 뷰에 UI 정보를 보관하는 것이 좋다고 생각합니다. – blu
으로 소프트웨어의 목표를 달성하고 리팩터링을 수행하십시오. – blu