Беспорядок между логикой представления и доменной логикой в веб-приложении MVC ASP.NET
Я запутываюсь между логикой Пользовательского интерфейса и доменом/прикладной логикой. Для иллюстрирования, что я пытаюсь закрепить я опишу мнимую программу ниже в целях иллюстрации:
(1) Предположите, что небольшое приложение с рядом 3 расположений каскадом выпадает. Поскольку Вы выбираете одно выпадающее, это инициировало Ajax jQuery, ДОБИРАЮТСЯ, который заканчивает тем, что поразил контроллер MVC, предоставляя выбранное значение ранее выбранный выпадающий. Контроллер возвращает допустимый выбор для следующего выпадающего. javacript (в представлении) располагает эти результаты в выпадающее. и так далее. Так каждый раз, когда Вы выбираете выпадающее, следующий заполняется.
(2) Теперь добавление ключа.. Существуют некоторые исключения. Позволяет говорят, выбирает ли пользователь "НЕЧТО" или "ПАНЕЛЬ" в первом выпадающем, то behavor изменяется, так, чтобы второе выпадающее было отключено, и третье выпадающее покажет texbox вместо этого.
Мои вопросы в контексте MVC, каково соответствующее место для этой логики "решения"? Такой как код, который ответственен за принятие этих решений как, я объяснил в (2). Самое удобное место, что я помещал это, было правильным в JavaScript представления. Я просто записал JavaScript, чтобы протестировать, если первым полем является "НЕЧТО" или "ПАНЕЛЬ" затем, отключите второй dropwdown и выгрузите третье выпадающее для текстового поля. Но это не чувствует себя совершенно правильным мне. Поскольку кажется, что это должна быть бизнес-логика поэтому, код должен принадлежать доменного слоя некоторое место. Но это не чувствует себя совершенно правильным также.
И таким образом, я чувствую, что вхожу в круги. Кто-то может пролить некоторый свет на этот небольшой дизайн?
4 ответа
Не раскалывая слишком много волос и не становясь слишком фанатичным на ЧТО ДОЛЖНО ПРИНЯТЬ, чтобы ПОЛУЧИТЬ ЦЕЛЬ ПАТТЕРНАЯ ...
Очевидно, что контроллер знает, что это изменение должно произойти, так как он будет обрабатывать оба результирующих случая (выпадающие выделения или ввод текста). Поэтому логика, связанная с этим, в контроллере не грех.
Также очевидно, что вид должен изменить способ отображения в зависимости от содержимого первого выпадающего списка. Хотя такое смешение поведенческих характеристик не совсем лучшее из того, что я могу себе представить в пользовательском интерфейсе, если необходимо, то логика для этого должна в определенной степени существовать в пользовательском интерфейсе. Но, черт возьми, это сайт , о котором мы говорим здесь. Вы действительно хотите удалить всю логику из javascript и перенести ее в метод контроллера? View решает, как отображать данные, что является его задачей, и поэтому не может быть грехом.
Реальный способ избежать сжигания на костре - это перепроектирование, чтобы избежать противоречий в первую очередь. Или просто закодируйте его и сучьте о своих паршивых требованиях к дизайну за пивом.
В вашем примере я бы не возражал против такой логики в контроллере, она определенно не принадлежит доменной модели. Лично мне было бы лучше взять ajax GET-запрос в контроллере и решить, что выводить оттуда с помощью JSON, вместо того, чтобы делать всю эту логику в jQuery (мне просто удобнее на C#, чем на javascript). При этом мне нравится держать свои методы экшена худыми, так что я бы поместил логику, связанную с выяснением того, что заполнять дроудауны методом на контроллере и украсил бы его [NonAction].
.В той ситуации, когда у Вас происходят очень специализированные действия, Вы должны поместить это в логику в js, как Вы это делали в своем выпадающем примере. Вы также всегда захотите поместить валидацию на стороне сервера, чтобы убедиться, что ваши данные чисты.
С выходящими материалами MVC 2 у них происходит действительно отличная валидация на стороне сервера/клиента. Загляните в пост Scott Gu, чтобы узнать больше об этом: Пост в блоге MVC 2
Давайте начнем с модели домена. Модель домена - это API, который моделирует домен технологически нейтральными способами. Она ничего не знает о таких технологиях View, как JQuery, HTML или (если уж на то пошло) XAML или Windows Forms.
Доменная модель содержит классы и интерфейсы, которые описывают Домен и позволяют моделировать Доменные концепции богатым и выразительным образом - неважно, какое приложение вы разрабатываете.
С учетом этого достаточно легко заметить, что описываемая вами логика отображения не принадлежит Доменной модели. Поэтому она должна принадлежать на уровне UI.
Вы можете поместить ее в отдельный модуль UI Logic или вместе с вашим приложением UI - в вашем случае с приложением ASP.NET MVC. Выражаете ли Вы желаемую логику пользовательского интерфейса в JavaScript или на стороне сервера - менее важно.
Лично я бы определил эту логику на стороне сервера в Partial Views, но это потому, что меня очень волнует тестируемость, и я знаю, как я буду тестировать юнит-тестировать такое поведение (мне сказали, что можно тестировать юнит-тестировать и код JQuery, но я понятия не имею, правда это или нет).
Если вы когда-нибудь напишете другое приложение, основанное на той же модели домена, то очень вероятно, что логика отображения окажется очень разной, так как разные технологии подразумевают разные парадигмы.
.