저는 한 달 전에 n 계층 응용 프로그램의 데이터 액세스 계층에서 엔티티/모델에 직접 액세스한다는 어리 석음을 발견했습니다. ASP.NET MVC를 연구하는 동안 ViewModels에 대해 읽은 후에는 UI 레이어가 상호 작용하는 모델이 데이터 액세스 레이어가 액세스 할 수있는 모델과 달라야한다는 사실을 알게되었습니다.모델/엔티티 및 N 계층 응용 프로그램
하지만 비즈니스 계층은 어떻습니까? 내 비즈니스 계층에도 다른 모델 세트를 사용해야합니까? 진정한 관심의 분리를 위해서 DAL에서 어떤 엔티티 (예를 들어, 엔티티 프레임 워크 또는 EJB에 의해 생성 될 수 있음)를 사용하지 않거나 비즈니스 환경과 관련이없는 특정 모델 세트를 사용해야합니까? 과잉 살인?
ASP.NET MVC는 MVVM (Model-View-ViewModel) 방식으로 잘 처리됩니다. 즉, 각 뷰는 하나의 ViewModel 만 가져옵니다.이 뷰 모델은 해당 뷰를 제공하는 전용 모델입니다.
예를 들어 Orders 뷰에 OrderDetail 및 Customer 데이터가 필요한 경우 이 해당 뷰에서 요구하는 엔터티의 데이터 만 표시하는 ViewModel을 만듭니다. ViewModel은 여러 (또는 필요한 경우 하나의) 엔티티에서 데이터를 함께 집계하는 역할을합니다.
귀하의 엔티티와 비즈니스 로직은보기/ViewModel 레이어의 "아래"에 위치하므로 구현을 인식하지 못합니다.
예, 가능합니다. 그러나이 특정 솔루션은 코드를 복잡하게 만들고 유사한 속성과 데이터를 가진 수많은 POCO로 이어지지 만 무의미합니다.
그러나보기를 렌더링하는 데 사용 된 개체와 데이터를 나타내는 데 사용하는 개체를 구분하는 것이 중요합니다.
복잡성은 내가 두려워했던 것이 었습니다. 중요한 점은 DAL이 제공하는 구현에 의존하지 않고 비즈니스 로직을 분리하여 뷰를 분리하는 것입니다. – Jonn
DAL의 구현 (이 경우 엔티티 프레임 워크)에 따라 비즈니스 로직을 유지해야한다는 의미입니까? – Jonn
비즈니스 계층은 엔터티에 종속되어야합니다 (예). Entity Framework 4에서는 POCO (Plain Old CLR Objects)가 될 수 있습니다. –
EF 4를 아직 보지 않으 셨습니다. 그것을 볼 수 있습니다. – Jonn