Я пытаюсь понять и реализовать различные шаблоны пользовательского интерфейса в .NET, чтобы увидеть плюсы и минусы и то, где они лучше всего подходят.
Я понимаю основную концепцию, но я создавал приложение, и возник вопрос.
Скажем, у нас есть класс Customer, который представляет основную информацию о клиенте.
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public string PhoneNumber { get; set; }
}
Теперь, если я создам WebView или WebForm, чтобы показать всем клиентам, я могу использовать этот класс, чтобы установить в качестве источника f.e. для DGV, имея возможность показать все свойства выше.
Но затем я хочу показать, например, представление / форму с историей доходов каждого клиента.
Итак, есть класс CustomerRevenue, как
public class CustomerRevenue
{
public Revenue ActualYearExpectedRevenue { get; set; }
public IList<Revenue> RevenuePerYearList { get; set; }
public decimal ActualYearProjectedRevenue => CalculateYearProyection();
public decimal CalculateYearProyection(int year)
{
var daysInYear = DateTime.IsLeapYear(year) ? 365 : 366;
var actualYearRevenue = RevenuePerYearList.SingleOrDefault(x => x.Year == year);
var dayNumber = DateTime.Now.DayOfYear;
var projection = ((actualYearRevenue.Amount * daysInYear) / dayNumber);
return projection;
}
}
Здесь, чтобы установить RevenuePerYearList, нам нужно время, так как, скажем, мы продаем много и имеем огромный список продаж с огромными списками статей, поэтому для расчета требуется некоторое время.
Итак, теперь мой вопрос:
Должен ли я тогда иметь "конкретные" классы для каждого вида / модели с данными, которые я хочу показать, то есть здесь у меня было бы кроме Customer класса, скажем, CustomerRevenueModel
public class CustomerRevenueModel
{
private readonly CustomerRevenue _customerRevenue = new CustomerRevenue();
public int Id { get; set; }
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string Country { get; set; }
public string PostalCode { get; set; }
public CustomerRevenue CustomerRevenue
{
get { return _customerRevenue; }
}
}
}
, который имеет (может быть) различные свойства, поэтому мне нужно при необходимости загружать эти "тяжелые" свойства
или
я должен остаться только с одним классом (я имею в виду, у клиента всегда есть доход) и оставить свойства "пустыми"?
Первый вариант дает мне много классов, по одному на каждое представление / форму, для которых я хочу показать данные (возможно, возможность многократного использования некоторых моделей в различных представлениях / формах), но сохраняет все в чистоте и в действительном состоянии. А также у каждого класса может быть своя собственная логика (логика предметной области - DDD)
Второй вариант - это меньше классов, меньше кода, но каким-то образом я получаю огромный класс (Бог) со всеми свойствами, которые есть у Customer, и всей его логикой (методами). Я загружаю только те, которые мне нужны, но мне это кажется очень плохим.
Третий вариант заключается в том, чтобы иметь большой класс со всеми свойствами и методами в качестве моей (доменной) модели, и создавать «ViewModel» (которая не содержит методов, только реквизиты) каждый раз, когда мне нужно показать что-н. как выше, используя его в качестве источника для моего GridView. Это решение с большим количеством классов и кода (большой класс + ViewModels + (возможно) DTO), а также с более организованным и твердым дизайном для моих глаз ... Здесь использование Mapper, такого как AutoMapper, действительно поможет, отображая объекты
Но это та часть, в которой я запутался ...
Являются ли эти "ViewModels" плохим паттерном, использующим MVC или MVP?
Это то же самое, что виртуальная машина в MVVM? Что я не думаю, так как я понимал VM в MVVM как «шаблон», но то, о чем я говорю, мне кажется больше похожим на DAO ??
Или они не имеют ничего общего, просто DAOs
Я думаю, что я немного запутался во всех различных значениях Model, ViewModel и т. Д. В различных шаблонах проектирования.
Я едва пытаюсь понять правильные MVC, MVP, MVVM и DDD, и я думаю, что иногда я смешиваю термины ...?