Трехуровневая архитектура ASP.NET MVC. Где проводить валидацию данных?

Question

[Евгений]

Суть заключается в следующем, мне необходимо в проекте реализовать трехуровневую архитектуру и в качестве уровня представления должен выступать ASP.NET MVC, у меня встал вопрос где должны валидироваться данные, в классическом MVC валидация происходит в самом контроллере, например задаем моделям ограничения с использование DataAnnotations а в контроллере просто проверяем ModelState и в случае ошибки выводит это в представление.
Но в случае трехуровневой архитектуры валидация как я понимаю должна происходить на уровне логики (BLL), т.е. контроллер должен передать данные на уровень BLL, затем они там валидируются и в случае ошибки BLL должен вернуть какое-то сообщение контроллеру, чтобы он вывел это в представление.

Как вариант можно делать двойную проверку, т.е. на уровне UI (в MVC проекте) и в BLL, тогда мы избавимся от проблемы того, как правильно отобразить пользователю сообщение об ошибке, но придется дублировать проверки т.к. на уровне BLL обязательно должны валидировать данные.

Может кто-то объяснить как это правильнее реализовать, и желательно привести любой пример.

Comments

[Евгений]

П.С. Также меня мучает вопрос, обязательно ли использовать на каждом уровне свои уникальные объекты? Т.е. на уровне DAL будут к примеру: User, на уровне BLL UserDTO, на уровне UI UserView. Или можно на всех трех уровнях использовать объект User?

Answer 1

[Петр]

На уровне BLL вы валидируете вхождение значений в установленные границы и корректность значений,
а на уровне MVC наличие и соответствие типов.

Comments

[Евгений]

Ну к примеру, пользователю надо ввести свое ФИО, нам на уровне представления кроме соответствия типов надо еще проверить, а не превышает ли он длину к примеру 50 символов, и на уровне BLL опять же будет это проверят. Как тут быть? Если прислушаться вашего совета, то на уровне представления, длину проверять мы не будет, но в случае если на уровне BLL выясниться что он превысил длину в 50 символов, как мне сообщить это пользователю? Вот в чем я запутался.

[Петр]

Евгений: У вас и на клиенте/веб странице будет еще валидация данных введеных в форму. А без нее вы увеличите нагрузку на сервер, трафик и удобство работы с формой для пользователя. Вас эта двойная проверка не беспокоит? Также в BLL можно сделать дополнительный метод с облегченной проверкой, который может вызываться только из контролера.

[Евгений]

Петр: Т.е. вы предлагаете следующее: валидируем данные на стороне клиента (Javascript), отправляем в контроллер, контроллер отправляет данные в BLL и там данные опять валидируется и только затем передаются в DAL? Ну в принципе я так и хотел делать, но является ли это правильным со стороны проектирования? Т.е. если в будущем если мы изменим способ валидации (к примеру не 50 символов а 49), нам придется менять проверку сразу и в BLL и в Javascript? Просто я делаю тестовое задание, мне надо его сделать максимально правильно, чтобы меня взяли на работу).
И еще такой вопрос, где происходит валидация регулярных выражений, к примеру для EMAIL, опять же и на клинет, и в BLL?

[Петр]

Евгений: Вы рассматривайте BLL как отдельную библиотеку которую может подключить десктопное приложение, сервис или web сервер и тогда будет более понятно как и что валидировать.

Answer 2

[MrDywar Pichugin]

Проверять можно на всех уровнях.
1) Контроллеры MVC - FluentValidation
2) Далее все через контракты.
Через IoC обертываем все в интерфейсы, и далее:

[ContractClass(typeof(IArrayContract))]
public interface IArray
{ контракт }

[ContractClassFor(typeof(IArray))]
internal abstract class IArrayContract : IArray
{ проверка входных и выходных параметров контрактов }

+ проверки на интерфейсах можно включать и выключать на вкладке свойств проекта, 4 уровня проверки.
+ проверки внедряются во все типы реализующие контракт.
- нельзя просто так взять и перехватить тип исключения от контракта, придется ловить все.

Из BBL не выкинишь HTTP ошибку, придется либо делать фильтр, либо ловить их в каждом методе и через switch кидать, но это не очень.