Cuando se utilizan objetos de negocio reutilizables, ¿qué se considera la mejor práctica al crear modelos de vista?
Usamos un objeto que llamamos Builderpara construir nuestros modelos de vista. Un generador para cada unidad lógica de vistas (pedidos, usuarios, etc.), donde cada unidad puede contener varios modelos de vistas diferentes (los pedidos contienen resumen, líneas de pedido, etc.).
Un constructor puede extraer datos a través de uno o más objetos comerciales estándar para construir un modelo de vista.
¿Qué se considera la mejor práctica cuando se trata de usar objetos / modelos comerciales en modelos de vista?
Enfoque 1
¿Permitir el uso de objetos comerciales en el modelo de vista?
//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
}
Enfoque 2
Tome solo los datos necesarios de los objetos comerciales
//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
}
Puedo ver los beneficios y los inconvenientes de ambos, pero me pregunto si hay un enfoque aceptado. En el enfoque 1, no hay duplicación de código alrededor de los modelos, pero crea una dependencia en la lógica de negocios. En el enfoque 2, solo toma los datos necesarios para la vista, pero duplica el código alrededor de los modelos.
fuente
La opción 1 es preferible ya que evita la duplicación de código. Eso es.
Si el modelo de dominio cambia significativamente, es casi seguro que la vista tendrá que cambiar de todos modos. Con la opción 2, debe cambiar el modelo de vista Y el constructor, así como la vista misma. Ese tipo de cosas es un veneno absoluto para la mantenibilidad. YAGNI
El punto de tener un modelo de vista separado es mantener un estado que sea significativo solo para la vista (por ejemplo, qué pestaña está seleccionada actualmente) separada del modelo de negocio. Pero los datos comerciales en sí deberían reutilizarse en lugar de duplicarse.
fuente
Los principios y mantras a veces son valiosos para guiar el diseño ... pero aquí está mi respuesta práctica:
Imagine que sus modelos de vista se serializan en JSON o XML. Si intentas serializar tus modelos de dominio, terminarás con un horrible desastre de texto y muy probablemente tendrás problemas con referencias circulares y otros problemas.
El propósito de un modelo de vista no es agrupar modelos de dominio para que la vista pueda consumirlos. En cambio, el modelo de vista debería ser un modelo completamente plano de la vista ... lo que estás viendo en la pantalla. Su lógica de vista solo debe ocuparse de estructurar los datos que están presentes en el modelo de vista.
Idealmente, su modelo de vista debería estar compuesto casi por completo por cadenas preformateadas. Piénselo ... ni siquiera quiere un DateTime o un decimal en su modelo de vista porque entonces está atrapado haciendo lógica de formato en C #, Javascript, Objective-C, etc.
fuente