При использовании бизнес-объектов многократного использования, что считается наилучшей практикой при построении моделей представлений?
Мы используем объект, который мы вызываем, 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 вам необходимо изменить модель представления и конструктор, а также само представление. Такие вещи являются абсолютным ядом для обслуживания. YAGNI.
Смысл наличия отдельной модели представления состоит в том, чтобы сохранять состояние, которое имеет смысл только для представления (например, какая вкладка выбрана в настоящее время), отдельно от бизнес-модели. Но сами бизнес-данные следует использовать повторно, а не дублировать.
источник
Принципы и мантры иногда ценны для руководства дизайном ... но вот мой практический ответ:
Представьте, что ваши модели представлений сериализуются в JSON или XML. Если вы попытаетесь сериализовать свои доменные модели, вы в конечном итоге получите отвратительный текстовый беспорядок и, скорее всего, столкнетесь с проблемами с циклическими ссылками и другими проблемами.
Цель модели представления не состоит в том, чтобы сгруппировать модели предметной области так, чтобы представление могло использовать их. Вместо этого модель представления должна быть полностью плоской моделью представления ... фактическая вещь, на которую вы смотрите на экране. Ваша логика представления должна касаться только структурирования данных, присутствующих в модели представления.
В идеале ваша модель представления должна состоять почти полностью из предварительно отформатированных строк. Подумайте об этом ... вам даже не нужен DateTime или десятичное число в вашей модели представления, потому что вы застряли, делая логику форматирования в C #, Javascript, Objective-C и т. Д.
источник