최근에 나는 빈맥 모델을 사용하여 n 계층 응용 프로그램을 만들고 있음을 깨달았습니다. 많은 사람들이 적절한 OO 방식을 사용하지 않는다고 주장합니다 (실제로는 반 패턴입니다) .빈혈 도메인 모델 및 ObjectDataSource
이제 도메인 기반 디자인을 대신 적용하려고합니다.
필자는 objectdatasource를 사용하여 그리드보기와 같은 컨트롤을 비즈니스 개체에 바인딩하는 데 익숙합니다. 도메인 모델에서 objectdatasource를 어떻게 사용하는지 혼란 스럽습니다. objectdatasource에 빈혈 모델이 필요합니까?
나는 모든 objectdatasources를 제거하는 것을 고려하고 있었는데, 어쨌든 (특히 코드 및 예외 처리를 디버깅 할 때) 부담이되는 것을 알았지 만, 나는 '적절한'일을하는 방법을 알고 싶습니다. 입니다.
나는 ASP.NET에서 많은 경험이 없지만 일반적으로 바위에서 데이터 바인딩을한다고 생각합니다. 그것은 많은 이점을 제공하므로 너무 쉽게 삭제하지 마십시오.
열쇠는 우려를 분리하는 것입니다. 데이터를 렌더링하는 방법은 도메인 모델 자체와 아무런 관련이 없으므로 도메인 모델을 뷰에 매핑하는 프리젠 테이션 로직 레이어 프리젠 테이션 로직 레이어를 만드는 것이 더 좋습니다.
즉, 도메인 모델을 중립적으로 유지하면서 많은 예상치 못한 방식으로 도메인 모델을 공개 할 수 있습니다. 앞으로는 도메인 모델을 기반으로 WCF 서비스 또는 일괄 작업 또는 WPF/SL 리치 클라이언트를 구현하라는 메시지가 표시된다고 가정 해보십시오. 특정 UI 기술 (예 : ASP.NET)에 묶여있는 많은 특성을 사용하지 않고도 이러한 예기치 않은 요구 사항을 처리 할 수 있어야합니다. 당신이 ViewModels 또는 프리젠 테이션 모델 당신의 뷰의 각이있는 경우
, 당신은 그 모델에 대해 databanding를 사용할 수 있습니다. ASP.NET에서이 기능이 얼마나 잘 작동하는지 모르지만 ASP.NET MVC 및 WPF의 매력처럼 작동하며 현재 Silverlight 4에 내장되어 있습니다 ...
개인적으로 나는 대상의 빈혈을 판단 할 때 지속성을 배제하는 데별로 신경을 쓰지 않습니다. 객체의 비즈니스 행위는 그것이 영속성을 유지하는지, 어떻게 지속되는지에 대해 직각이어야합니다.
동작은 루트 문제를 해결하는 데 도움이되는 기능에 관한 것이어야합니다. 나는 가치 값이 더 많은 객체를 디자인 할 때 CRUD 작업에 대해 걱정할 필요가 없다는 것에 집중할 것입니다.