Я пытаюсь структурировать свое приложение WPF MVVM в соответствии с лучшими практиками. Я должен начать с большого количества существующего кода, поэтому у меня нет возможности сразу решить все структурные недостатки. Мне нравится следующая структура решения.
http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/
Это разделяет решение на следующие проекты; BusinessLogic, BusinessObjects, Infrastructure (общие утилиты многократного использования), оболочка WPF и модули (компоненты приложения, которые нужно внедрить с помощью контейнера IOC).
Я понимаю, что бизнес-объект представляет сущность человеческого мира, тогда как бизнес-логика - это детали реализации, как обсуждалось в этом вопросе.
Что такое бизнес-объекты и что такое бизнес-логика?
Поэтому, используя MVVM, бизнес-объект становится просто тупым контейнером, который на самом деле ничего не делает, кроме как ожидает изменения своих свойств внешней бизнес-логикой? Я не понимаю, как вы отделяете бизнес-объект от бизнес-логики до такой степени, что вы можете иметь их в отдельных сборках.
Возьмите следующий чрезвычайно упрощенный код:
public class Chart
{
private SizeChart _activeChartSize = new SizeChart();
public void Draw() {
// Size the chart object
_activeChartSize.Size(this);
// Do other draw related things
}
}
public class SizeChart
{
public void Size(Chart chartToSize) {
// Manipulate the chart object size
}
}
В контексте структуры решения MVVM, описанной выше (по крайней мере, на мой взгляд), класс SizeChart будет бизнес-логикой, а класс Chart будет бизнес-объектом, но размещение их в разных проектах будет циклической зависимостью. Является ли бизнес-логика класса SizeChart бизнес-объектом и где должен находиться класс SizeChart в структуре решения, если я приму эту предложенную структуру решения MVVM?
Извините, если это невероятно очевидный и простой вопрос для некоторых людей, но трудно, когда вы не можете начать с чистого листа, чтобы узнать, как лучше всего начать переводить плохо структурированный код в хорошо структурированный код.