일부 비즈니스 개체/POCO/엔티티/기타가있는 비즈니스 계층이 있습니다. 또한 데이터 액세스를위한 저장소가 있습니다. 지금까지는 UI 레이어에서 저장소에 직접 액세스했습니다. 나는 실제로 직선적 인 CRUD가 아닌 클래스를 좀 더 필요로하므로 논리와 CRUD를 수행 할 몇 가지 비즈니스 로직 클래스를 생성 할 것이고 리포지토리에 의해 액세스되지 않을 것입니다. 더 이상 UI (아마 처음부터 완료되었을 것입니다).비즈니스 논리 클래스 이름 지정
이러한 클래스는 무엇이라고해야합니까? 내가 생각할 수있는 유일한 것은 서비스 클래스이지만,이 응용 프로그램에는 실제 WCF 서비스가 있으므로 혼란 스럽습니다. WCF 서비스도 이러한 클래스를 사용하므로 서비스 클래스를 사용하는 것은 이상하고 혼란스럽게 보입니다.
"서비스"명명 규칙도 사용합니다. "서비스"가 업계에서 매우 과부하 된 용어가되었지만 이것이 가장 합리적입니다. 코드를 검토하는 개발자는 응용 프로그램/도메인 서비스와 WCF 서비스의 차이점을 확인할 수 있어야하며 WCF 서비스 호출을 사용하는 동안 다른 서비스 클래스가 혼동스러워 보일 수도 있지만 그렇지 않다는 것을 알게 될 것입니다. 서비스의 개념은 기능을 수행하는 코드이며 다른 코드에서 사용할 수 있다는 것입니다. 내부 서비스 일 수도 있고, http를 통해 외부에 노출 된 서비스 일 수도 있습니다. 그러나 코드가하는 일의 아이디어는 동일합니다. 귀하의 '서비스'도메인 객체의 번호를 사용하여 비즈니스 로직을 조율하는 경우
, 당신은 가능성이 Facade Pattern 구현하고 - 그래서 아마도이 접미사로 이름을 지정할 수 있습니다, 당신의 묘사에서 예를 들어 OrderManagementFacade
, 그것은 소리 WCF 클래스와 마찬가지로 실제로 호스트 서비스를 구현하고 있습니다. 필자는 일반적으로 이러한 클래스의 이름을 "ServiceHost"접미사로 지정합니다. 실제 서비스 클래스와 잘 구분됩니다.
예를 들어 비즈니스 로직을 "CustomerService"클래스에두고 해당 WCF 클래스의 이름을 "CustomerServiceHost"로 지정합니다.
이 패턴은 나에게는 새로운 것이지만 나는 그것을 좋아한다. 그것은 "서비스"와는 달리 매우 서술 적입니다. –
도메인 개체가없고 이러한 "서비스"가 논리를 직접 수행 할 때를 제외하고는 설명적인 것입니다. – Vakho