Ищите способ уменьшить дублирование кода проверки в моих View Models и Logical Layer

Question

Прямо сейчас приложение, создаваемое нашей командой, использует встроенные атрибуты MVC и несколько домашних атрибутов для проверки моделей просмотра.Из-за лучших принципов проектирования, мы поместили те же правила в логический слой.К сожалению, это вызвало дублирование кода проверки.

По крайней мере, в MVC3, если JavaScript отключен, эти же атрибуты все равно будут выполнять проверку, для которой они предназначены, поэтому преобразование модели представления в DTO и запросЛогический уровень для проверки его не является вариантом, потому что этот процесс уже был бы выполнен фреймворком.

Я не обнаружил, что следующий пост SO может помочь.Я использовал MS Enterprise Library, и API не подходил нашей команде.

Полезные советы по предотвращению дублирования логики проверки при работе с объектами домена и моделями представления в ASP.NET MVC

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

Answer 1

Один из способов увидеть это: если ваш API - это ваше приложение MVC, и проверка уже выполнена к моменту выполнения ваших бизнес-правил, вы можете просто предположить, что они действительны.Это проверка входных данных, конечно, что-то, связанное с вашим доменом, но ... если вы измените образ мышления, ваш домен ожидает действительных данных и предполагает, что вы выполнили домашнюю работу, прежде чем использовать бизнес-правила.

Answer 2

Вы запрашиваете несколько типов проверки, которые будут выполнены здесь. Вам нужна проверка клиента (кажется) и какой-то другой уровень проверки бизнеса.

Если это так, то единственные варианты, которые я вижу, это:

1. продублируйте код (я знаю, что я в списке) 1a. используйте аннотации данных на ваших объектах для проверки клиента. Проверка бизнес-уровня происходит, как вы ее определяете, и разделяется как окончательная проверка. Например, если вы используете плавный API-интерфейс сущностной структуры, это стандартный маршрут.
2. проверка на стороне клиента - это всего лишь помощники на стороне клиента. проверка домена произойдет после сохранения. В идеале это более мощный подход, но он не так удобен, когда ваши доменные объекты не совпадают с именами свойств в ваших моделях представления, поэтому вам необходимо отобразить ошибки домена, чтобы просмотреть ошибки свойств модели, которые обычно не так уж плохи, но могут оказаться ненадежными .
3. реализовать IValidteableObject (и избавиться от проверки клиента). Эта логика проверки вызывается из вашего логического уровня и связующего элемента модели.
4. Вы можете ввести код для проверки, но это не красиво, и я не уверен, насколько многократно он используется вне маршрута проверки MVC.

Могут быть и другие способы, помимо этого, но это основные варианты, как я понимаю.