엔티티 프레임 워크 POCO + 권장 패턴

Question

우리는 EntityFramework (CTP5)를 상당히 좋아하며 ASP.NET MVC3과 함께 사용합니다.

내가 싫어하는 것은; 모든 것이 함께 섞여 있습니다.

난 데이터베이스 검증에 믹스 인하고 의미 같은 클래스에서 함께 일부 비즈니스 로직 및 alltogether UI를 DisplayAttribute, RequiredAttribute, RangeAttribute, CompareAttribute을 배치 할 수 있습니다. ScriptIgnore 속성을 Json DTO 개체로 사용자 정의 할 수도 있습니다. 따라서 Persistance, Presentation, DTO 및 Business Object에 대해 동일한 POCO 클래스를 사용할 수 있으며 내 domian 모델로 사용할 수 있습니다.

EF POCO + MVC3 도구 세트와 함께 어떤 디자인 패턴을 따르십니까? 어떤 층이 있습니까? 클래스에 어떤 resposibilities를 추가합니까 (귀하의 POCO 클래스도 도메인 모델입니까)

Answer 1

저는이 문제를 해결하기 위해보기 모델을 사용합니다. 유효성 검사 및 UI 표시 특성은 뷰 모델로 이동합니다. 이 패턴에서 컨트롤러는 저장소를 사용하여 EF 모델을 가져오고,이 EF 모델을 뷰 모델 (이 경우 AutoMapper을 사용)에 매핑하고 뷰 모델을 뷰에 전달합니다. 뷰 모델에는 모든 UI 표시 특성이 포함되어 있으므로보기는 예상대로 동작합니다. 각보기에는 고유 한보기 모델이 있어야합니다. 즉, 동일한 EF 모델과 연관된 여러보기 모델을 가질 수 있지만 속성의 다른 하위 집합을 포함하고보기의 특정 요구 사항에 따라 서식 지정 속성을 표시 할 수 있습니다.

프로세스는 다른 방법으로도 작동합니다. 컨트롤러는보기에서 뷰 모델을 인수로받습니다. 뷰 모델을 다시 모델에 매핑하고 EF 모델을 저장소에 전달합니다. UI 유효성 검사 속성은 다른보기에서 서로 다른 유효성 검사 요구 사항을 가질 수 있으므로보기 모델에서 처리됩니다. 예를 들어보기 삽입/업데이트를 생각해보십시오. 삽입보기에서 새 엔티티를 작성하므로 Id 특성은 필요하지 않습니다. 이 경우에는 뷰 모델에 Id 속성이 없어도됩니다. 반대의 업데이트보기에서는 Id 속성이 필요합니다.

Answer 2

내 POCO 클래스는 거의 항상 도메인 모델이며 거의 모델을 볼 수 없으므로 이러한 문제가 없습니다.

컨트롤러에서보기 (또는 JsonResult)로 데이터를 전달할 때 특별한 "보기 모델"클래스를 사용하는 것이 가장 좋습니다. 이 경우 해당 뷰 모델에서 UI 기반 특성을 표시합니다. 대부분의 경우 (순결한 응용 프로그램 제외) 도메인 객체를 더 많이 또는 덜 표시해야하므로 ViewData를 직접 사용하지 않는 한 일부보기 모델이 필요합니다.

도메인 개체의 데이터 주석은 비즈니스/데이터 수준 유효성 검사에 사용하려는 경우에만 해당됩니다.이 유효성 검사는 다른 규칙과 UI 유효성 검사를 수행 할 수 있습니다.

POCO 클래스가 도메인 객체 인 엄격한 DDD를 따르려면 객체의 인스턴스에서 도메인 논리를 수행하는 메소드를 제공하십시오. 그런 경우 비즈니스 facede가 도메인 객체를 컨트롤러에 노출시키지 않아야합니다. 이 경우 비즈니스 외관에 노출되고 컨트롤러에서 소비되는 데이터 전송 객체로 끝납니다. 나는이 시나리오에서 순수 주의자가 아니므로 DTO에서 데이터 주석을 직접 사용하는 것에 마음을 열지 만 다른 요구 사항에 따라 달라집니다.