RIA 서비스가 포함 된 Entity Framework, Silverlight - 디커플링 대 빠른 개발의 균형

Question

최근에 Entity Framework, WCF RIA Services 및 Silverlight 4를 사용하여 놀았습니다. 이러한 응용 프로그램을 얼마나 빨리 개발할 수 있는지 감탄했습니다. 도구를 사용하면 EF 모델에 DataAnnotations로 포함 된 특정 유효성 검사를 자동으로 인식하는 Silverlight UI와 같이 "무료"로 많은 것을 얻을 수 있습니다. 그러나 대규모 응용 프로그램 에서처럼 비즈니스 로직 및 UI를 포함하여 전체 응용 프로그램을 통해 EF에 대한 종속성을 갖는 것이 바람직하지 않은 것처럼 보입니다.

나는 Entity Framework와 함께 POCO/IPOCO를 사용할 수 있다는 것을 알고 있으며, 그것은 확실히 나를위한 선택 사항입니다. 그러나 그러한 경로를 선택하면 Silverlight와 같은 "자동화 된 기능"중 일부가 추가 작업없이 모델 유효성 검사를 표시 할 수 있습니다.

사람들은 어떻게 처리합니까? 다른 레이어를 EF에서 분리하기 위해 다른 레이어 사이에 인터페이스를 배치하고 일부 기능을 포기합니까? 아니면보다 신속한 개발을 위해 감 결합을 포기합니까? 내 케이크를 먹고 그것을 먹을 수있는 방법이 있습니까?

Answer 1

나의 그룹은 현재이 정확한 문제를 겪고 있습니다. 우리는 모두가 만족스러워하는 적절한 타협안을 찾았습니다. 모든 일이 끝나기 전에 프로젝트가 시간이 지남에 따라 더욱 복잡해지고 유지 관리가 중요하다는 점을 명심하십시오. 가능한 한 코드 재사용을 늘려 UI (또는 단위 테스트)를 바꾸는 것이 최소화됩니다.

이 모든 것을 감안할 때 우리는 EF를 UI로 끝까지 밀어 넣는 대신 잘 정의 된 도메인 계층을 선호했습니다. 이는 모델을 애플리케이션의 핵심으로 만들고 데이터베이스의 스키마를 준수하도록 강제하지는 않습니다. 나는 EF가 개념적 모델로 추상화하려고 시도했음을 압니다. 그러나 우리는 전체 스택을 위해 EF에 의존하기가 점점 어려워지는 작은 잡동사니로 계속 달려 왔습니다. 예를 들어, EF를 사용하여 비즈니스 논리를 적용 할 수있는 좋은 곳은 없습니다. 우리는 요새를 인터셉터에 넣고 싶지 않았으며 UI에 넣고 싶지 않았습니다. 물론, 이에 대한 현명한 해결 방법이있을 수 있지만, 우리가 추진하고있는 방향을 좋아하지 않았습니다.

타협점은 EF를 사용하지만 데이터 저장소와 도메인 모델간에이를 유지하는 것이 었습니다. 이렇게하면 우리는 여전히 DataReader에 대해 프로그램 할 필요가 없으며 도메인의 자체 추적 엔터티의 이점을 활용할 수 있습니다. 그런 다음 우리 도메인에서 UI로 기본 WCF 서비스 (RESTful 아님)를 노출합니다.

우리에게 추가 검증 작업은 실제로 그렇게 큰 것이 아니 었습니다. 물론 초기 릴리스에는 약간의 시간이 걸리지 만 전체 프레임 워크의 복잡성으로 마무리하지 않기 때문에 전체 유지 관리주기가 오래 걸리는 것은 아닙니다.