2008-11-05 10 views
7

W środowisku ASP.NET MVC wymagane jest użycie przyrostka "Kontroler" dla wszystkich kontrolerów. Wydaje się to niepotrzebnie restrykcyjne - czy istnieje ku temu techniczny powód?Dlaczego kontrolery są oparte na nazwach ASP.NET MVC?

Jestem po prostu ciekawy, ale widzę sytuacje, w których bardziej elastyczne zasady nazewnictwa mogą poprawić organizację kodu. Czy nie można łatwo wykryć możliwych klas kontrolerów za pomocą refleksji w celu wyszukania klas pochodnych Controller? Lub wymagają, aby klasy kontrolerów były oznaczone jako ControllerAttribute?

+0

@ shog9: Dzięki za poprawę alfabetyzacji. –

+0

@Austusto: bez problemu. – Shog9

Odpowiedz

14

Społeczność MVC jest pod silnym wpływem Ruby on Rails, która ma wartość "convention over configuration". Konsekwentnie nazywając rzeczy, aplikacja może działać z zerową konfiguracją.

+0

Uderzyłeś mnie w to! Oto link: http://en.wikipedia.org/wiki/Convention_over_configuration –

+0

Tak; dzięki. Ja też to złapałem. –

3

Jedną z zalet tej konwencji jest to, że często segment adresu URL, kontroler i klasa modelu mają taką samą nazwę.

URL:/product/ Kontroler: Produkt: Kontroler Model: Produkt

To spowodowałoby konflikt nazw. Zrobiliśmy więc konwencję, aby nazwy kontrolerów były oznaczone "Kontrolerem", aby uniknąć tego konfliktu. Można jednak zastąpić to zachowanie za pomocą interfejsów API rozszerzalności.

+0

Właściwie Phil ... Przez REST te segmenty adresów URL powinny nadawać nazwy kolekcjom, co oznacza, że ​​kontrolery są zwykle w liczbie mnogiej, jak w 'ProductController' (/ products/1), podczas gdy encja modelowa jest pojedyncza jako' Product', ponieważ kolekcja wyświetlająca widoki użyje modelu 'IEnumerable '. Więc i tak nie byłoby żadnych starć. Ale konwencja jest dobra, ponieważ jest używana również gdzie indziej (bez ludzi narzekających), jak w atrybutach, kolekcjach, słownikach, listach itp. Te typy również * konwencjonalnie * używają przyrostków. Oczywiście ze względów związanych z rozwojem aplikacji. –

Powiązane problemy