Проверка правил на уровне Data или Domain?
верхний регистр (строка) и нижний регистр (строка)
4 ответа
В архитектуре MVC M (модель) включает оба уровень домена и уровень доступа к данным . Так что в примере Сандерсона нет ничего плохого.
Тем не менее, когда вы реализуете модель предметной области с использованием обоих этих уровней (вместо того, чтобы иметь только один), логика проверки должна переходить на уровень предметной области, чтобы повысить согласованность объектов предметной области и избежать дублирования логики проверки во многих местах (например, в каждом конкретном хранилище).
Они определенно относятся к вашему уровню домена (где вы могли бы реализовать IDataErrorInfo , но это было бы полезно только для приложений Windows Forms или WPF, я думаю
Похоже, эта философия проверки очень похожа на философию, изложенную Полом Стовеллом (ознакомьтесь с этой его статьей ). Это очень мощный инструмент, и я часто им пользуюсь. В основном:
- Нет ничего плохого в наличии недопустимого бизнес-объекта, если вы не пытаетесь его сохранить.
- Любые и все нарушенные правила должны быть извлечены из бизнес-объекта, чтобы привязка данных, как а также ваш собственный код, вы можете увидеть, есть ли ошибки, и обработать их соответствующим образом.
Итак, как бы неосведомлен ваш уровень домена , он имеет значение постоянства, Я считаю, что ваши сущности должны хотя бы знать о том, когда они сохраняются. Метод Save - это способ сделать их ответственными за свою сохраняемость (которые они впоследствии могут делегировать на уровень доступа к данным ). Я не вижу в этом ничего плохого.
Я обычно предпочитаю всегда действительные объекты домена. Объекты домена могут быть изменены только методами, которые не позволяют объекту стать недействительным.
С другой стороны, объекты представления могут содержать временные недопустимые значения или значения, которые не могут быть правильно проанализированы. Но вызовы методов будут выдаваться объектам домена только на уровне представления, когда данные действительны.
Объекты домена обеспечивают соблюдение инвариантов, объекты представления указывают пользователю, как он должен изменить свой ввод с учетом ограничений.
Проверка должна выполняться на уровне вашего домена. Ваша бизнес-логика является частью домена, а не доступом к данным. Проверка не может выполняться внутри самого объекта домена (фактического класса), но она должна находиться внутри уровня домена.