Где лучше всего разместить логику проверки с учетом этого дизайна приложения?

Question

Рассмотрим проект веб-приложения ASP.NET MVC 2, в котором используются объекты POCO EF4 и шаблон хранилища для хранения информации в базе данных SQL Server. Пока есть 3 проекта, 4, если считать базу данных:

1.) Domain.dll, не имеет зависимостей, предоставляет интерфейсы POCO и репозитория.

2.) Storage.dll, зависит от домена, реализует интерфейсы репозитория (используя EF 4).

3.) Mvc.dll, зависит как от # 1, так и от # 2, обеспечивает уровень пользовательского интерфейса.

4.) База данных SQL Server + подключение, независимость от dll (без зависимостей).

Допустим, я добавляю еще одно веб-приложение для размещения службы данных WCF, которая обеспечивает подачу OData базы данных с использованием Domain.dll и Storage.dll:

5.) Provider.dll, в зависимости от домена и хранилища, обеспечивает уровень обслуживания OData.

Куда относится логика проверки домена в этом решении? Если классы POCO домена украшены проверочными атрибутами, нужно ли службе данных WCF что-либо еще для защиты данных? Является ли когда-либо хорошей / плохой идеей поместить логику проверки в хранимые процедуры и почему?

Answer 1

Я бы сказал, поместите DataAttributes в домен и используйте проверку в MVC для части MVC и используйте Ent Lib для проверки в службе WCF.В качестве альтернативы вы можете использовать проверку Ent Live в MVC и WCF, но это не то, о чем идет речь.Я не знаю, что это должно сводиться к семантике DDD.MVC выполняет проверку моделей, когда у них есть DataAttributes, так что следуйте этому и сделайте то же самое в WCF.

Answer 2

Я пометил это как субъективен и логичным, потому что даже сообщество DDD не может сделать свой ум об этом.

Сколько слоев вам нужно изменить, если появится новое требование проверки для Customer.LastName?Может ли уровень пользовательского интерфейса информировать пользователя о том, что уровни домена, wcf, web, базы данных отклонили их команды?Каким образом есть ограничение LastName, когда LastName не может превышать 50 символов в бизнес-домене?

Вы видите, что это действительно обсуждение, а не ответный вопрос.Кроме того, если вы используете OData в качестве базы данных для своих служб, вы не используете DDD.Вы используете Persistance-As-Model или DDD-Lite.Это на самом деле вредно и приводит к таким вопросам, которые пытаются решить проблемы с использованием двух несовместимых шаблонов вместе.