MVC 3 и DRY пользовательская проверка - PullRequest
Новая
       55

MVC 3 и DRY пользовательская проверка

2 голосов
/ 27 февраля 2011

Если я что-то упустил (что очень возможно), мне кажется, что пользовательская проверка всегда нарушала DRY.Во всех примерах, которые я видел, даже с использованием новой ненавязчивой проверки клиента, представленной с MVC 3, мы должны создавать код .NET для проверки на стороне сервера и jQuery (или код JavaScript) для проверки на стороне клиента.

Я понимаю, что не существует такого понятия, как переводчик .NET-to-jQuery, который бы облегчил проверку DRY сервера / клиента, и я полагаю, что это был бы единственный способ получить настоящую DRY-проверку, которая работает как на сервере, так ина стороне клиента.

Но я был бы совершенно доволен тем, что на сервере всегда выполнялась пользовательская проверка.Данные, необходимые для передачи в пользовательскую проверку (в моем случае), обычно ограничены одним или двумя полями, и логика на стороне сервера обычно довольно быстрая, даже если она должна попасть в базу данных.

Есть линет механизма OOTB для подключения пользовательской проверки с использованием атрибутов, а затем, когда ваша проверка на стороне клиента использует Ajax для выполнения проверки на стороне сервера и ответа клиенту?Или кто-то придумал такое решение?

Или, в конце концов, это вопрос компромисса повторения пользовательской проверки лучше, чем проблемы, возникающие при постоянном выполнении пользовательской проверки на стороне сервера?

Заранее спасибо.

Ответы [ 3 ]

2 голосов
/ 27 февраля 2011

AFAIK, нет ничего OOTB (Из коробки).

Что касается компромиссов - хотя нарушая DRY, вы получаете несколько вещей:

  • Немедленная обратная связь с пользователем (улучшено удобство использования)
  • Нет ошибок в случае ошибок проверки (меньше нагрузка на сервер)

Конечно, кроме нарушения СУХОГО и открытия себя для этой проблемы, вы также получаете большую полезную нагрузку для клиента (дополнительный JavaScript).

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

1 голос
/ 27 февраля 2011

OOTB: http://msdn.microsoft.com/en-us/library/system.web.mvc.remoteattribute(v=vs.98).aspx

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

Когда люди задают этот вопрос, что довольно часто, если вы ищите, я обычно отсылаю их к понятию DDD ограниченных понятий .Использование [Remote] и принудительное использование DRY, когда дело доходит до проверки, приводит к объединению множества проблем в одном месте и объединению обязанностей нескольких уровней.Бизнес-логика против постоянства и логики целостности данных (ненулевые).

@ Дарин Дмитров говорит, что довольно хорошо во многих своих ответах на этот точный вопрос.Проверка того, что обязательное поле заполнено, сильно отличается от того, чтобы убедиться, что у Салли достаточно кредитов для совершения покупки, и к ней следует относиться по-разному.

Проверка клиента лучше всего использовать для базовых задач, а не перегружать более тяжелымиоперации.Влияние на юзабилити от проверки клиента действительно минимально.Нет ничего «непригодного» для публикации формы и ожидания обновления.Это более свободно, но не все, что сделает или сломает успех вашего приложения.

0 голосов
/ 27 февраля 2011

Я не особо разделяю ваши опасения по поводу нарушения принципа СУХОЙ в этом случае, но похоже, что пара других людей уже обсуждала это.

Однако ваша идея очень похожа на новую функцию удаленной проверки, добавленную в MVC 3:

Как: реализовать удаленную проверку в MVC3

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

...