Путаница между логикой представления и логикой домена в веб-приложении ASP.NET MVC

Question

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

(1) Представьте себе небольшое приложение с набором из 3-х каскадных выпадающих меню. Когда вы выбираете один выпадающий список, он запускает JQuery Ajax GET, который в конце концов попадает в контроллер MVC, предоставляя выбранное значение ранее выбранного выпадающего списка. Контроллер возвращает допустимые варианты для следующего раскрывающегося списка. Javacript (в представлении) упорядочивает эти результаты в раскрывающемся списке. и так далее. Поэтому каждый раз, когда вы выбираете раскрывающийся список, заполняется следующий.

(2) Теперь закидываю гаечный ключ .. Есть несколько исключений. Допустим, если пользователь выбирает «FOO» или «BAR» в первом раскрывающемся списке, то поведение изменяется, так что второе раскрывающееся меню отключается, а в раскрывающемся списке «три» вместо этого отображается текстовое поле.

Мои вопросы, в контексте MVC, каково подходящее место для этой логики "принятия решений"? Например, код, который отвечает за принятие таких решений, как я объяснил в (2). Самое удобное место, которое я поместил, было прямо в javascript представления. Я просто написал javascript, чтобы проверить, является ли первое поле «FOO» или «BAR», затем отключить второе раскрывающееся меню и заменить третий раскрывающийся список для текстового поля. Но это не совсем правильно для меня. Кажется, это должна быть бизнес-логика, поэтому код должен принадлежать некоторому месту на уровне домена. Но это тоже не совсем правильно.

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

Answer 1

Давайте начнем с модели предметной области. Доменная модель - это API, моделирующий Домен технологически нейтральными способами. Он ничего не знает о технологиях View, таких как JQuery, HTML или (в этом отношении) XAML или Windows Forms.

Модель предметной области содержит классы и интерфейсы, описывающие домен, и позволяет моделировать понятия предметной области богатым и выразительным способом - независимо от того, какой тип приложения вы разрабатываете.

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

Вы можете поместить это в отдельный UI Logic модуль или вместе с вашим UI-приложением - в вашем случае приложение ASP.NET MVC. Независимо от того, выражаете ли вы желаемую логику пользовательского интерфейса в JavaScript или на стороне сервера, менее важно.

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

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

Answer 2

Не расщепляя слишком много волосков или не становясь слишком фанатичным на ЧТО ДОЛЖНО БЫТЬ СДЕЛАНО, ЧТОБЫ ХРАНИТЬ РИСУНОК ЧИСТО * ...

Очевидно, что Контроллер знает, что это изменение должно произойти, так как он будет обрабатывать оба возникающих случая (выпадающий выбор или ввод текста). Поэтому размещение логики, связанной с этим, в контроллере не грех.

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

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

Answer 3

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

С выходом MVC 2 у них есть действительно отличная валидация на стороне сервера / клиента. Посмотрите на сообщение Скотта Гу: Сообщение в блоге MVC 2

Answer 4

Учитывая ваш пример, я не возражаю против этой логики в контроллере, она определенно не относится к модели предметной области. Лично мне было бы лучше получить запрос GET ajax в контроллере и решить, что выводить оттуда с помощью JSON, вместо того, чтобы выполнять всю эту логику в jQuery (я просто чувствую себя более комфортно в C #, чем в javascript). С учетом вышесказанного, я хотел бы сохранить свои методы действия более тонкими, поэтому я бы использовал логику, связанную с выяснением того, как заполнить выпадающие списки в методе контроллера, и украсил бы его [NonAction].