Где и когда я должен проверять свои данные при использовании EF и POCO?

Question

Я запустил проект, чтобы посмотреть, что EF 4 может делать с POCO.Я создал БД и пользовательский POCO.Теперь я хочу проверить свои данные.Для этого я использую Блок 5 проверки корпоративной библиотеки.

У меня нет проблем, включая проверку в моих POCO через атрибуты и использование ее с Entity Framework, но это означает, что мои POCO больше не будут POCO, посколькуя вставил зависимость в структуру валидации.

Любой совет, где я должен вставить часть валидации и сохранить POCO чистыми?

Answer 1

Лично я не вижу большой проблемы с проверкой в ​​качестве части сущностей - в конце концов, сущности являются частью вашей доменной модели, и, возможно, можно придумать правила валидации,как часть их атрибутов.Я не эксперт в области моделирования доменов:)

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

Answer 2

Я хотел бы создать класс обслуживания и выполнить проверку в этом классе.

Например, у вас есть класс POCO, называемый Listing.Создайте класс обслуживания с именем ListingService.Затем выполните проверку в ListingService в методе с именем ValidateListing.

Answer 3

Я согласен с тем, что вы хотели бы защитить свои организации от проверки.Это не входит в обязанности ( SRP ) самого объекта домена.

Помимо проверки на основе атрибутов, блок прикладных программ проверки VAB также поддерживает проверку на основе конфигурации.Здесь можно следовать двум моделям:

1. Использовать конфигурацию на основе XML.Это хорошо поддерживается.VAB содержит инструмент конфигурирования, который позволяет вам сконфигурировать все без написания одной строки XML.Особенно инструмент 5.0 очень хорош.Тем не менее, использование XML затрудняет рефакторинг чего-либо в вашей модели (однако модульные тесты помогут вам быстрее обнаружить ошибку).

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

Удачи.