Martin Fowler suggests 도메인 모델과 "데이터 로더"사이의 경계로 서비스 계층을 사용합니다. 그러나 Rockford Lhotka는 비즈니스 개체 자체에 대한 유효성 검사를 제안합니다. 이는 CSLA.NET이하는 것과 정확히 같습니다.유효성 검사 및 서비스 계층 또는 비즈니스 개체에서?
이것을 서비스 계층으로 추상화하면 서비스 계층이 여러 비즈니스 개체에서 활동/작업을 조정할 수 있다는 이점이 있습니다. 그러나 비즈니스 로직 및 유효성 검사를 위해 비즈니스 개체를 직접 사용하는 것보다 서비스 계층을 사용하는 다른 장점과 단점은 무엇입니까?
저는 Rocky Lhotka 캠프에 있습니다. 나는 비즈니스 객체가 애플리케이션과 UI 레이어 사이를 "포팅"하는 것이 매우 쉬워야한다고 생각한다. 추가 "서비스 계층"을 추가하면 개체에 대한 종속성이 추가되어 이동성이 떨어집니다.
비즈니스 오브젝트 프레임 워크를 올 Y 르게 작성하면 비즈니스 오브젝트가 여러 비즈니스 오브젝트 사이의 올 Y 른 유효성 검증을 처리 할 수 있어야합니다. CSLA.NET은 종속 속성 유효성 검사의 개념뿐만 아니라 부모/자식 관계를 사용하여 올바르게 수행합니다.
당신이 이것을 알아 낸 것인지 확실하지 않습니다.
Martin Fowler는 PEAA에서 UI (또는 클라이언트)와 도메인/데이터 계층 간의 API 인 서비스 계층을 제안합니다. 클라이언트가 사용할 수있는 모든 기능을 노출합니다.
도메인 모델 (Here)
행동과 데이터를 모두 통합 도메인의 개체 모델을 보면.
도메인 계층 액션/검증 (행동)과 상태 (데이터)이 객체가 다른 응용 프로그램에서 재사용 할 수
해야합니다 이러한 개체를 포함,이 또한 당신의 디자인에 따라 달라집니다. 도메인 계층은 서비스 계층에 종속적이어서는 안됩니다.
따라서 Domain 객체에는 동작 (유효성 검사 포함) 및 데이터가 포함되어 있습니다. 서비스 레이어는 응용 프로그램이 노출되도록하려는 것입니다 (functionaly로). IE는 고객 또는 계좌를 추가하여 월 말 청구서를 계산합니다.
날카로운 architure의 레이아웃에서보세요 ( http://www.sharparchitecture.net/)이이 METERIAL에 대한 이해이다.
HTH
뼈
나는 데이터 및 행동의 분리가보다 유연한 도메인 모델을 찾고 있어요,하지만 난 서비스 레이어 동작에 해당하는 계층이다 믿지 않는다 . 대신 Business Entity 객체가 데이터 만 노출하고 Business Process 객체는 동작을 노출하는 간단한 비즈니스 로직 계층 접근 방식을 취할 수 있으며 이러한 동작 중 유효성 검사 메소드가 될 수 있습니다.
하나의 이점은 느슨한 비즈니스 프로세스 커플 링의 정도에 따라 유효 범위를 넓은 범위의 공변수 및 경우에 따라 불변 유형에 적용 할 수 있다는 것입니다."FirstName"과 "LastName"필드의 유효성 검사를 한 번 고려해보고,이 필드가 대형 시스템에서 6 개 이상의 다른 엔터티에 존재할 수도 있다고 생각하십시오. 프로세스를 데이터와 분리하면 검증 프로세스를 한 번 구현하여 동일한 데이터를 제공하는 많은 개체에 적용 할 수 있습니다.
데이터 모델과 동작이 융합 된 도메인 모델로 구성되어야한다는 이상적인 아이디어는 2000-2002 년 Fowler/Evans의 개념입니다 (빠른 마이그레이션 직후). 2 티어 애플리케이션 대신 분산 정보 시스템을 지향한다.)
생각들?
일부 비즈니스 개체가 조정을 수행 할 수도 있습니다. 예를 들어 주문을 송장으로 변환하는 데 필요한 동작을 작성하지 않을 경우 주문을 확인하고 Valide가 변환 할 OrderConverter를 갖게됩니다. 내가 일반적으로 "서비스"객체로 보는 것은 근본적으로 거의 관련없는 메소드의 투기장입니다. 그들은 모두 가게에 뭔가를하지만 그 외의 것은 관련이 없습니다. Csla에서 이러한 방법은 일반적으로 사용 사례에 대한 완전한 지식을 가진 별도의 클래스로 캡슐화됩니다. 주문 방법에 대한 모든 것을 알고 있습니다 – Andy