Каков хороший способ реализации логических проверок в MVVM?

Question

Я использую шаблон MVVM для нового программного обеспечения .Net с графическим интерфейсом WPF.Проверка свойств проходит хорошо с использованием IDataErrorInfo, где загораются все поля.Однако я ищу хороший способ реализовать какую-то бизнес-логику.

Простой пример;Если у вас есть таблица, которая содержит столбцы, я использую интерфейс IDataErrorInfo, чтобы проверить, не является ли имя пустым / допустимым.Но я также хочу убедиться, что имя столбца уникально.Возможно также, что столбец используется в другом месте, поэтому его нельзя удалить.

Есть предложения о том, как реализовать бизнес-логику с использованием MVVM?Оглядывался, похоже, не могу найти «правильного» решения.

Answer 1

Расположение бизнес-логики всегда сложно при использовании шаблона MVVM. Вопрос всегда в том, это модель или модель?

Полагаю, это зависит от того, где вы проверяете дублирование.

Если вы пытаетесь запретить пользователю дублировать данные, представленные в представлении, вы должны выполнить проверку в связанной модели представления.

Если вы пытаетесь запретить пользователю дублировать данные, присутствующие либо в модели, либо в связанном слое данных (чтение БД), то это следует выполнить в домене модели.

Единственное, что вам нужно иметь в виду, - это то, что ваш код представляет данные в представление о дублировании, но это зависит от представления, чтобы решить, следует ли его представлять.

Довольно часто я помещаю большое количество бизнес-логики и «вспомогательных» функций в отдельный проект библиотеки классов и вызываю функциональные возможности там, где это лучше всего. Это может упростить переключение функциональности с модели представления на модель и наоборот.

Вы видели страницы шаблонов msdn MVVM? Посмотрите здесь .

Помните, однако, что, как и во всех вещах, должен быть принят прагматический подход. Могут быть случаи, когда бизнес-логика устройства находится в коде View позади, но она всегда должна быть минимальной.

Answer 2

Я хотел бы порекомендовать эту книгу (ссылка на Amazon.com): Создание корпоративных приложений с помощью Windows Presentation Foundation и шаблона представления модели представления модели

Хотя в нем только MVVMего название дает широкий спектр тем и возможных способов организации и структурирования приложений.

В нем я нашел много полезных идей и предложений.

Единственный недостаток, который я вижу, эточто это не идет слишком глубоко в отдельных темах.С другой стороны, вы можете прочитать его быстро, и нет необходимости читать каждую главу последовательно, но сосредоточиться на том, что вы просто ищете.

Книга поможет вам получить общее представление о том, что вы хотели бызнаю и хорошую отправную точку, где вы могли бы углубиться позже.

Answer 3

В моем использовании MVVM в WPF и Silverlight бизнес-логика обычно реализуется глубже в доменном слое, доступном через службы различным потребителям.Что касается реализации логики предметной области таким более абстрактным образом, существуют бесконечные варианты, зависящие от сложности вашего приложения и от того, насколько динамичны ваши бизнес-правила.

Некоторые скажут, что проверка объектов домена должна осуществляться в IOCинъекционные сервисы проверки, а не запекания в самих объектах домена (если это не является абсолютно ядром, неизменяющей логику в вашем домене).

Я обычно нахожу этот подход немного излишним.Вы могли бы сделать так, чтобы ваши доменные объекты реализовывали некоторый интерфейс проверки, который потенциально может связывать проверку по всему графу объектов.Доменные объекты могут включаться в разделяемые бизнес-правила либо встроенным, либо динамическим образом, например, правило, которое проверяет состояние объекта домена и связанных с ним объектов и добавляет запись в коллекцию нарушенных бизнес-правил.