В чем преимущество использования нескольких классов контроллера в ASP.NET MVC?

Question

Я просто изучаю основы ASP.NET MVC и задаюсь вопросом, в чем преимущество состоит в том, чтобы разбить логику веб-сайта среди нескольких контроллеров, а не просто иметь один класс Controller, который управляет всем сайтом, а не просто упорядочивать код лучше. (На мой взгляд, только последнее преимущество не должно быть достаточным для того, чтобы повлиять на конечного пользователя через URL из-за разделения проблем: детали реализации сайта не должны отражаться в URL-адресах, которые использует сайт, нет?)

Некоторые примеры контроллеров, которые я читал, показывают разные контроллеры для таких вещей, как «Продукт» или «Пользователь» или «Сообщение». Они явно соответствуют классам объектов, за которыми следуют действия, которые могут быть предприняты над ними (глядя на URL прямо сейчас, я вижу stackoverflow.com/questions/ask).

Есть ли преимущество разделения сайта на отдельные классы контроллеров, такие как QuestionsController, и только один контроллер по умолчанию и обработка этих действий внутри него, например stackoverflow.com/ask-question (к тому же он выглядит немного уродливее).

Я спрашиваю, потому что я не особо заинтересован в том, чтобы сделать мой сайт RESTful (я немного посмотрел на него, но считал его слишком ограниченным) и вместо этого предпочитаю параметры строки запроса для передачи информации о запросе. Поэтому концепция разделения URL-адреса на контроллер и действие для меня не имеет смысла, поскольку информация о действии и классе будет представлена ​​в строке запроса.

Наконец, я предпочитаю более простой вид URL-адресов, например, www.mysite.com/about, по сравнению с www.mysite.com/home/about (что это значит?), Снова заставляя меня задаться вопросом, на самом деле это несколько контроллеров.

Answer 1

Красота ASP.NET MVC происходит из-за того, что это делает разделение проблем настолько простым. В отличие от ASP.NET Webforms, где каждая страница является по существу View и Контроллером, в ASP.NET MVC вы можете абстрагировать логику модели в отдельные проблемы или «группы функций». Имеет смысл иметь ProductController, который обрабатывает все, что связано с Продуктами, потому что тогда вы можете изолировать каждый набор связанных функций в своем приложении в однородные группы, которые независимо проверяются и поддерживаются.

Наличие DoEverythingController принципиально нарушает рассуждения о MVC, поскольку он объединяет всю модельную логику вместе в одну гигантскую миску спагетти кода, а не поддерживает ее аккуратно и организованно. Кроме того, наличие контроллера, который делает все, не является особенно объектно-ориентированным и напоминает более процедурный подход к развитию, например, многие (более старые) веб-сайты PHP, которые имеют некоторые центральные «функции.php» или аналогичные, что делает все. Это грязно и дезорганизовано.

Что касается вашей конечной точки, механизм маршрутизации в MVC позволяет вам строить маршруты к заданным действиям контроллера, как вы хотите. Действие About() действия ControllerX и Contact() ControllerY может иметь как корневые URL-адреса, такие как/about и/contact, если вы определяете маршруты соответственно.

Edit (слишком долго для комментариев)

Вообще говоря, классы контроллеров будет довольно тонким, насколько код и логика обеспокоен. Хорошо спроектированные контроллеры часто передают более сложные операции, такие как извлечение данных из хранилища данных в какой-то сервис, так что площадь поверхности для отказа остается небольшой. Несмотря на «тонкость» большинства контроллеров, чем больше ваш сайт, тем больше операций потребуется, и более громоздким будет ваш универсальный контроллер. Даже в сценариях, отличных от MVC, огромные файлы сосать для поддержки и обновления (например, «functions.php» выше).

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

Answer 2

Вы можете получить практически любую схему URL, которую вы желаете, с помощью ASP.Net MVC Routing. Какие контроллеры у вас есть и где ваши действия живут не имеет ничего общего с вашими URL-адресами. Только маршрутизация определяет ваш URL. Таким образом, существует без причины, чтобы пожертвовать ясностью кода и организацией ради конкретной схемы URL.

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

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

Answer 3

chaiguy

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

пара с хорошим шаблоном хранилища для доступа к данным и некоторыми отличными шаблонами T4, и вы более или менее получаете легко понятную работу «сантехника», созданная бесплатно.

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

Answer 4

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

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

Следовательно, несколько контроллеров.

Answer 5

Предпочитает иметь все файлы в одном каталоге или хранить файлы в разных папках. Сохраняя приложение организованное в отдельном контроллере помощи во многих случаях:

выступление 1) памятей

Различного из Java Servlet, где контроллер совместно betwen много запроса в ASP NET MVC контроллера создается для каждого запрос. Каждый раз, когда пользователь делает запрос, приложение должно создать контроллер. Подумайте о сравнении сравнений betwen создайте в памяти экземпляр fatcontroller из 100k VS одного экземпляра контроллера света 1k.

2) OO выгода

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

Например, вы можете создать контроллер для «продуктов» и простирается от него, чтобы создать контроллер для «овощей продукции» и так далее ..

3) Безопасность.

Предположим, что в вашем приложении вы имеете страницу, выполнять действия CRUD на данном пункте вашего дб: - дисплей - редактировать - обновление - удалить

Вы хотите сделать эту страницу зарезервированный только для зарегистрированных пользователей.

Если вы поместите весь этот метод в один отдельный контроллер, вы можете поместить аннотацию [Авторизовать] на контроллер, и по умолчанию все методы внутри контроллера будут защищены. Если поместить все приложения в одном контроллере жира вы должны быть осторожны, чтобы поместить [Авторизовать] на каждого метода (что Happe если вы простите поставить пометку на удаление метода?)

[Authorize] 
public class ProductController 

public ActionResult Index(String id) { 
    ... 
} 

public ActionResult Update(String id) { 
    ... 
} 

public ActionResult Delete(String id) { 
    ... 
} 

4) Безопасность снова.

Предположим, вы пишете классический CRUD (Create Read Update Delete). Теперь вы хотите удалить весь CRUD.

Если вы сохраняете код отдельно в другом контроллере, вы просто удаляете контроллер, управляющий CRUD. Если вы держите все вместе в fatcontroller, вам нужно искать методы, которые задерживают CRUD во всем коде. Опять же: что, если вы забудете удалить метод Delete?

5) Практичность

Если вы положили все вместе, вы будете иметь такие методы, как это:

product_edit 
product_delete 
product_rate 
product_create 
category_edit 
category_delete 
category_create 

Если вы организовать код в отдельный контроллер вы будете иметь

product 
    edit 
    delte 
    create 
    rate 
category 
    edit 
    delete 
    create 

Это хорошо по многим причинам: хотите изменить продукт в товаре? просто рефакторинг и переименуйте productController в itemController.