데이터 모델이 UI 및 도메인 모델과 얼마나 밀접하게 매핑됩니까? - 예를 들어,UI 중심 및 도메인 중심 데이터 모델 - 장단점
데이터 모델은이 경우, 예를 들어, 등
고객 테이블, 직원 테이블이 UI가 너무 밀접하지만 데이터 모델을 반영하지 않을 수 있습니다 도메인 모델에 매우 근접 할 수 있습니다 고객 데이터의 비트 - 앤 - 피 (bit-and-piece)를 다른 여러 비트의 데이터와 함께 공급하는 여러 형식이있을 수 있습니다. 이 경우 각 양식의 데이터를 보유 할 별도의 테이블을 가질 수 있습니다. 필요에 따라 향후 데이터를 결합 할 수 있습니다. 또는 양식 데이터를 Customer 테이블에 직접 삽입하여 데이터 모델이 UI와 잘 관련되지 않도록 할 수 있습니다.
당신에게 더 좋은 점이 무엇인가?
도메인 모델을 해결하려는 실제 문제에 맵핑하는 것이 더 깨끗해졌습니다.
그러면 뷰에 필요한 모든 데이터의 버킷 역할을하는 뷰 모델을 만들 수 있습니다. 언급 한 바와 같이
, 당신의 UI는 자주 변경 될 수 있지만, 보통은 태클하는 특정 도메인 문제를 변경하지 않습니다 ...
정보는 여기에서이 패턴에서 찾을 수 있습니다 :
http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
UI는 많은 요구에 따라 변경 될 수 있으므로 일반적으로 어느 UI에서나 추출 된 도메인 모델에 데이터를 보관하는 것이 좋습니다.
RESTful 서비스 계층이있는 경우 도메인 모델을 노출하는 항목. 이 경우 UI (특정 화면)는 이러한 서비스를 호출하고 수집 된 도메인 모델에서 화면을 구성합니다. 이 시나리오에서는 도메인 모델이 UI까지 계속 거품을 내뿜지만 UI 레이어는 필요한 특정 데이터를 제외하고 특정 화면을 만듭니다. 지속성을 위해 도메인 모델을 사용하는 것에 대해서도 흥미로운 질문이 있습니다. 여기 내 요점은 도메인 모델은 진실의 단일 소스가 될 수 있습니다. 그것은 데이터를 운반하고 논리를 꽤 잘 캡슐화하는 작업을 수행 할 수 있습니다. 필자는 각 도메인 모델을 DTO, VO, DO 및 what-have-yous로 변환하는 상용구 코드가 많은 프로젝트에서 작업했습니다. 많은 것은 매우 불필요 해졌으며 대부분의 경우 습관 때문에 더 많이 보입니다.
동의. 여기서 중요한 점은 구현 모델과 사용자의 정신 모델이 있다는 것입니다. 둘 다 일반적으로 서로 멀리 떨어져 있으며 사용자가 구현 모델에 대한 자신의 정신 모델을 잘못 적용하도록 강요합니다. – Joey