Usando objetos de negócios em modelos de exibição

Ao usar objetos de negócios reutilizáveis, o que é considerado uma prática recomendada ao criar modelos de vista?

Usamos um objeto que chamamos Builderpara construir nossos modelos de exibição. Um construtor para cada unidade lógica de visualizações (pedidos, usuários etc.), em que cada unidade pode conter um número de modelos de visualização diferentes (pedidos contém resumo, linhas de pedidos etc.).

Um construtor pode extrair dados através de um ou mais objetos de negócios padrão para construir um modelo de visualização.

Qual é considerada a melhor prática quando se trata de usar objetos / modelos de negócios em modelos de exibição?

Abordagem 1

Permitir o uso de objetos de negócios no modelo de exibição?

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

Abordagem 2

Pegue apenas os dados necessários dos objetos de negócios

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

Posso ver os benefícios e as desvantagens de ambos, mas me pergunto se existe uma abordagem aceita? Na abordagem 1, não há duplicação de código nos modelos, mas cria uma dependência da lógica de negócios. Na abordagem 2, você pega apenas os dados necessários para a exibição, mas duplica o código em torno dos modelos.

A opção 1 cria um forte acoplamento entre o modelo de domínio e a visualização. Isso contraria os próprios modelos de exibição de problemas criados para solucionar.

Um modelo de visualização "motivo para mudar" é se a própria visualização é alterada. Ao colocar um objeto de modelo de domínio no modelo de exibição, você está apresentando outro motivo para mudar (por exemplo, o domínio mudou). Esta é uma indicação clara de uma violação do princípio da responsabilidade única. Ter dois ou mais motivos para mudar leva a exibir modelos que exigem muita manutenção - provavelmente mais do que o custo de manutenção percebido da duplicação nos modelos de domínio / exibição.

Eu sempre defendia a abordagem 2. Geralmente, os modelos de exibição podem parecer muito semelhantes, até idênticos aos objetos de modelo de domínio, mas a distinção, como eu mencionei, são os diferentes motivos de mudança.

A opção 1 é preferível, pois evita a duplicação de código. É isso aí.

Se o modelo de domínio mudar significativamente, é quase certo que a visualização precisará mudar de qualquer maneira. Com a opção 2, é necessário alterar o modelo de vista E o construtor, bem como a própria vista. Esse tipo de coisa é um veneno absoluto para a manutenção. YAGNI.

O objetivo de ter um modelo de vista separado é manter o estado que é significativo apenas para a vista (por exemplo, qual guia está selecionada no momento) separada do modelo de negócios. Mas os dados de negócios em si devem ser reutilizados em vez de duplicados.

Por vezes, princípios e mantras são valiosos para orientar o design ... mas aqui está a minha resposta prática:

Imagine seus modelos de exibição sendo serializados em JSON ou XML. Se você tentar serializar seus modelos de domínio, terá uma bagunça hedionda de texto e provavelmente encontrará problemas com referências circulares e outros.

O objetivo de um modelo de visualização não é agrupar modelos de domínio para que a visualização possa consumi-los. Em vez disso, o modelo de vista deve ser um modelo completamente plano da vista ... a coisa real que você está vendo na tela. Sua lógica de visualização deve se preocupar apenas com a estruturação dos dados presentes no modelo de visualização.

Idealmente, seu modelo de visualização deve ser composto quase inteiramente de sequências de caracteres pré-formatadas. Pense nisso ... você nem quer um DateTime ou um decimal no seu modelo de exibição, porque fica parado fazendo lógica de formatação em C #, Javascript, Objective-C, etc.