Почему контроллеры MVC должны иметь завершающее соглашение "Контроллер" от имени своего класса?

Мне кажется смешным, что MVC не распознает контроллер, если у него нет "Контроллера", добавленного к имени класса. Этот ответ упоминает ControllerDescriptor и ControllerTypeCache как два места в MVC, где это соглашение настроено.

Мой вопрос - почему? Это явно не соглашение о конфигурации, так как IsControllerType в ControllerTypeCache проверяет, что класс:

  • Является общедоступным
  • Не абстрактно
  • Реализует IController
  • Заканчивается "Controller"

Кто-нибудь знает причину этого? После того, как все контроллеры, вероятно, будут в реальном проекте MVC, в папке с именем "Контроллеры", а простой двойной щелчок по файлу покажет нам, что класс наследует Controller.

Просто мне кажется глупым, но мне было интересно, существует ли фактическая причина, по которой они это сделали.

ИЗМЕНИТЬ

Только что увидели этот пост в блоге от Фила Хаака со вчерашнего дня, где он обсуждает решение этого соглашения - он имеет одинаковую мысль обо мне - Наверное, немного бессмысленно!

ОТВЕТЫ

Ответ 1

Пользовательский контроллер factory

Вы всегда можете предоставить настраиваемый контроллер factory, который по-разному разрешит эти классы. И я согласен с тем, что контроллерам не нужно добавлять имя типа контроллера, потому что в конце концов они похожи на любой другой класс. Их тип предков OOP определяет их как контроллеры в любом случае (IController, Controller...)

Возможно, Visual Studio?

Хотя это может иметь какое-то отношение к Visual Studio. Подобно классам атрибутов. Возможно, Visual Studio не предоставит дополнительные элементы контекстного меню для классов, которые не заканчиваются контроллером. При действии контроллера вы можете легко перемещаться (или создавать) к соответствующему виду.

Соглашения хороши

Итак скажут эксперты, и я согласен. Существуют и другие соглашения, подобные этим в рамках .net, но люди не жалуются на них.

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

Тип столкновения в соответствии с командой MVC Asp.net

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

public class ProductController : Controller
{
    public ActionResult Index()
    {
        // we'd have to distinguish this Product type here
        IEnumerable<Product> result = GetProducts();
        return View(result);
    }
    ...
}

Ответ 2

Первые 2 необходимы для того, чтобы mvc мог создать экземпляр контроллера, 3-й необходим, чтобы mvc знал, как использовать контроллер (вызвать метод Execute), и, я думаю, это просто найти тип быстрее.

Ответ 3

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

Например, если UX для работы с продуктами включает в себя список, вы можете просто вызвать контроллер ProductList, и его не следует путать со списком. Поскольку люди, которые мы легко устраняем неоднозначность каждый день на основе контекста, а именование в программном обеспечении не должно быть исключением. Теперь роль контроллера - это координация. В случае нашего ProductList. Он будет координировать действия, такие как ProductList.sort(byField), ProductList.delete(продукт).

Что касается использования концепции соглашения по конфигурации, это можно сделать на метауровне. В .Net можно использовать атрибут для идентификации контроллера или модели.

Какая большая сделка? Указание шаблона в названии предлагает ленивое именование и, следовательно, ленивое моделирование. Имя - это не просто имя, оно выбирает концепцию, которую вы используете для моделирования домена решения, смысл которого управляет решениями о том, какой код представляет эту концепцию и с каким кодом связан код. Чем более общие и/или неоднозначные ваши имена, тем больше вы предлагаете расширить дизайн и изменить его таким образом, который сложнее поддерживать.