뷰 모델에서 비즈니스 오브젝트 사용

재사용 가능한 비즈니스 오브젝트를 사용할 때 뷰 모델을 빌드 할 때 가장 좋은 방법은 무엇입니까?

우리는 Builder뷰 모델을 구축하기 위해 호출하는 객체를 사용합니다 . 각 논리적 뷰 단위 (주문, 사용자 등)에 대해 하나의 빌더로, 각 단위는 여러 가지 다른 뷰 모델을 포함 할 수 있습니다 (주문에는 요약, 오더 라인 등이 포함됨).

빌더는보기 모델을 빌드하기 위해 하나 이상의 표준 비즈니스 오브젝트를 통해 데이터를 가져올 수 있습니다.

뷰 모델에서 비즈니스 오브젝트 / 모델을 사용할 때 더 나은 방법은 무엇입니까?

접근법 1

뷰 모델에서 비즈니스 오브젝트를 사용할 수 있습니까?

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary();
        obModel.Order = obOrder;

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public Some.Business.Logic.Order Order;
    //Other methods for additional logic based on the order
    //and other properties
}

접근법 2

비즈니스 오브젝트에서 필요한 데이터 만 가져옵니다.

//Business object in some library
public class Order
{
    public int OrderNum;
    public int NumOrderLines;
    //...
}

//Order builder in website
public class OrderBuilder
{
    public OrderSummary BuildSummaryForOrder(int OrderNum)
    {
        Some.Business.Logic.Order obOrder = Some.Business.Logic.GetOrder(OrderNum);
        //Any exception handling, additional logic, or whatever

        OrderSummary obModel = new OrderSummary()
        {
            OrderNum = obOrder.OrderNum,
            NumOrderLnes = obOrder.NumOrderLines,
        }

        return obModel;
    }
}

//View model
public class OrderSummary
{
    public int OrderNum;
    public int NumOrderLines
    //Other methods for additional logic based on the order
    //and other properties
}

두 가지 장점과 단점을 볼 수 있지만 허용되는 접근법이 있는지 궁금합니다. 접근법 1에서는 모델을 중심으로 코드를 복제하지 않지만 비즈니스 로직에 대한 종속성을 만듭니다. 접근법 2에서는 뷰에 필요한 데이터 만 가져 오지만 모델 주위에 코드를 복제합니다.

옵션 1은 도메인 모델과보기를 밀접하게 연결합니다. 이것은 문제가되는 뷰 모델이 해결하도록 설계된 문제에 위배됩니다.

뷰 모델 "변경 이유"는 뷰 자체가 변경되는 경우입니다. 도메인 모델 객체를 뷰 모델에 넣으면 다른 변경 이유 (예 : 도메인이 변경됨)가 발생합니다. 이는 단일 책임 원칙을 위반했음을 분명히 나타냅니다. 변경해야 할 두 가지 이상의 이유가 있으면 도메인 / 뷰 모델에서 중복 된 유지 보수 비용보다 많은 유지 보수가 필요한 뷰 모델이 나타납니다.

저는 항상 접근법 2를 옹호합니다. 종종 뷰 모델이 도메인 모델 객체와 매우 유사 해 보일 수 있지만, 앞에서 언급 한 차이점은 변경 이유가 다릅니다.

옵션 1은 코드 중복을 피하기 때문에 바람직합니다. 그게 다야.

도메인 모델이 크게 변경되면 뷰가 변경되어야합니다. 옵션 2를 사용하면 뷰 자체와 뷰 모델 및 빌더를 변경해야합니다. 그런 종류의 것은 유지 보수에 대한 절대 독입니다. 야 그니.

개별 뷰 모델을 갖는 요점은 비즈니스 모델과 분리 된 뷰 (예 : 현재 선택된 탭)에 대해서만 의미있는 상태를 유지하는 것입니다. 그러나 비즈니스 데이터 자체는 복제하기보다는 재사용해야합니다.

원칙과 진언은 때때로 디자인을 인도하는 데 가치가 있지만 여기에 내 실제적인 답변이 있습니다.

뷰 모델이 JSON 또는 XML로 직렬화되는 것을 상상해보십시오. 도메인 모델을 직렬화하려고하면 텍스트가 엉망이되어 순환 참조 및 기타 문제가 발생할 가능성이 큽니다.

뷰 모델의 목적은 도메인 모델을 그룹화하여 뷰에서 사용할 수 없도록하는 것입니다. 대신 뷰 모델은 완전히 평평한 뷰 모델이어야합니다. 실제 화면에서보고있는 것입니다. 뷰 로직은 뷰 모델에있는 데이터 구조화에만 관심이 있어야합니다.

이상적으로는 뷰 모델이 거의 전부 사전 형식화 된 문자열로 구성되어야합니다. 생각해보십시오 ... 뷰 모델에서 DateTime 또는 10 진수를 원하지 않아도 C #, Javascript, Objective-C 등의 형식 논리를 수행하지 못하기 때문에