Что должны представлять мои ASP.NET MVC контроллеры - приложение "реального мира"

Question

У меня установлено веб-приложение, созданное как веб-приложение ASP.NET 3.5.Недавно мы изменили его, чтобы смешать MVC с приложением для некоторых новых функциональных возможностей.

Теперь, когда он здесь, мы хотим использовать MVC, где только возможно, чтобы начать «преобразовывать» приложение из неуклюжих веб-форм в более удобные и легко обслуживаемыеtestable MVC app.

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

Позвольте мне быть более подробным.

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

Существующий контроллер MVC в приложенииявляется MAPCONTROLLER, с 3 действиями, которые отвечают за генерацию данных HTML или JSON для размещения на карте.

Теперь нам нужно добавить маршрут MVC (контроллер + действие), чтобы позволить клиентскому представлениюсохранить некоторую информацию в качестве предпочтения.По сути, всякий раз, когда они на странице поиска смотрят на карту, они могут нажать кнопку с надписью «запомнить это как представление моей карты по умолчанию», и с этого момента их карта всегда будет начинаться с этого вида.

Мой вопрос (и я прошу прощения, но я хотел быть очень очень ясным, я вижу слишком много вопросов без контекста, чтобы помочь).Что должен представлять мой контроллер?У меня, очевидно, есть 3 основных системных направления.Было бы уместно создать новый контроллер SEARCH или PREFERENCES с действием SaveDefaultMapView (просмотр не требуется) или с привязкой к существующему контроллеру MAP, даже если эта новая функция больше связана с поиском и настройками, чем с фактическим созданием карты?Должен ли контроллер MVC быть в основном выровнен с экраном (страница поиска / поисковая подсистема), с доменом / данными, которыми манипулируют (предпочтения), или с очень специфическим визуальным элементом, находящимся под пристальным вниманием во время выполнения действия (карта)?

Все примеры и проекты bootcamp все хороши и хороши, но они слишком чисты и упрощены, чтобы их можно было применять в огромном устаревшем приложении.Как можно спроектировать свои компоненты MVC вокруг системы, которая объединяет множество проблем с доменом в одну веб-страницу?

Спасибо всем!

Answer 1

Спасибо, Роберт. Полагаю, я мог бы перефразировать немного ... какие руководящие принципы, по мнению других, могут быть полезными для поддержания организованности и логичности их обязанностей контролера? Хотя мой приведенный выше пример касается только 3 наших областей, я ожидаю в конечном итоге заменить большинство / все приложения на MVC. Кроме того, каждая из 3 упомянутых областей имеет отношения к множеству других областей (например, карты могут использоваться для построения нескольких объектов на основе местоположения, предпочтения могут применяться к любой области системы и, как и карты, способны выполнять поиск для нескольких видов хозяйствующих субъектов (по одному, а не все вместе). Таким образом, линии размыты. Мне интересно услышать, как другие нашли работающие руководящие принципы для организации диспетчера. О, и, по крайней мере, мы придерживаемся парадигмы тощий контроллер / толстая модель!

Answer 2

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

ASP.NET MVC в этом отношении прекрасно агностичен.Неважно, как вы проектируете свой контроллер / подструктуру маршрута, и он достаточно гибок, чтобы справиться с большинством любых проектов.

Дизайн вашего приложения должен быть тяжелым со стороны модели.Ваши контроллеры должны быть относительно маленькими;если вы обнаружите, что в контроллеры встраивается большое количество логики, вам следует рефакторинг этой логики в модель или добавить служебный слой, содержащий логику.Ваш уровень контроллера лучше всего рассматривать как «патч-панель»;это место, где вы подключаете свои входящие URL через маршруты к вашей модели / сервисному слою и вашему View Model / Views.

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