Używanie obiektów biznesowych w modelach widoku

Kiedy używa się obiektów biznesowych wielokrotnego użytku, co uważa się za najlepszą praktykę przy budowaniu modeli widoków?

Używamy obiektu, który nazywamy, Builderdo budowy naszych modeli widoków. Jeden konstruktor dla każdej logicznej jednostki widoków (zamówienia, użytkownicy itp.), Przy czym każda jednostka może zawierać wiele różnych modeli widoków (zamówienia zawierają podsumowanie, wiersze zamówień itp.).

Konstruktor może pobierać dane przez jeden lub więcej standardowych obiektów biznesowych w celu zbudowania modelu widoku.

Jaka jest najlepsza praktyka, jeśli chodzi o stosowanie obiektów / modeli biznesowych w modelach widoku?

Podejście 1

Zezwolić na użycie obiektów biznesowych w modelu widoku?

//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
}

Podejście 2

Pobieraj tylko niezbędne dane z obiektów biznesowych

//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
}

Widzę zalety i wady obu, ale zastanawiam się, czy istnieje zaakceptowane podejście? W podejściu 1 nie występuje powielanie kodu wokół modeli, ale tworzy zależność od logiki biznesowej. W podejściu 2 pobierasz tylko dane potrzebne do widoku, ale kopiujesz kod wokół modeli.

Opcja 1 tworzy ścisłe powiązanie między modelem domeny a widokiem. Jest to sprzeczne z bardzo problematycznymi modelami widoku zaprojektowanymi do rozwiązania.

Widok modeluje „powód do zmiany”, jeśli sam widok się zmienia. Umieszczając obiekt modelu domeny w modelu widoku, wprowadzasz kolejny powód do zmiany (np. Domena została zmieniona). Jest to wyraźny sygnał naruszenia zasady pojedynczej odpowiedzialności. Posiadanie dwóch lub więcej powodów do zmiany prowadzi do modeli podglądu, które wymagają dużo konserwacji - prawdopodobnie więcej niż postrzegane koszty utrzymania duplikacji w modelach domeny / widoku.

Zawsze opowiadałbym się za podejściem 2. Często zdarza się, że modele widoków mogą wyglądać bardzo podobnie, nawet identycznie jak obiekty modeli domen, ale rozróżnienie, o którym wspomniałem, jest ich różnymi przyczynami zmian.

Opcja 1 jest preferowana, ponieważ pozwala uniknąć duplikacji kodu. Otóż ​​to.

Jeśli model domeny zmieni się znacząco, jest prawie pewne, że widok i tak będzie musiał się zmienić. W przypadku opcji 2 musisz zmienić model widoku ORAZ konstruktora, a także sam widok. Tego rodzaju rzeczy są absolutną trucizną za łatwość utrzymania. YAGNI.

Istotą posiadania osobnego modelu widoku jest utrzymanie stanu, który ma znaczenie tylko dla widoku (np. Która karta jest aktualnie wybrana), odrębnego od modelu biznesowego. Ale same dane biznesowe powinny być ponownie wykorzystywane, a nie duplikowane.

Zasady i mantry są czasem cenne przy projektowaniu przewodnim ... ale oto moja praktyczna odpowiedź:

Wyobraź sobie, że twoje modele widoków są serializowane do JSON lub XML. Jeśli spróbujesz serializować swoje modele domen, skończysz z ohydnym bałaganem tekstu i najprawdopodobniej napotkasz problemy z okólnikami i innymi problemami.

Celem modelu widoku nie jest grupowanie modeli domen, aby widok mógł je wykorzystać. Zamiast tego model widoku powinien być całkowicie płaskim modelem widoku ... rzeczywistą rzeczą, na którą patrzysz na ekranie. Twoja logika widoku powinna dotyczyć tylko strukturyzacji danych obecnych w modelu widoku.

Idealnie twój model widoku powinien składać się prawie całkowicie ze wstępnie sformatowanych ciągów. Pomyśl o tym ... nie chcesz nawet DateTime ani wartości dziesiętnych w modelu widoku, ponieważ utkniesz w logice formatowania w C #, JavaScript, Objective-C itp.