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

Ответ 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 можно использовать атрибут для идентификации контроллера или модели.

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