Więc pracuję w .Net. Robię projekty open source w .Net. Jednym z moich największych problemów nie jest konieczność korzystania z .Net, ale ze społecznością i otaczającymi go ramami. Wszędzie wydaje się, że magiczne schematy i ciągi nazewnictwa są traktowane jako najlepszy sposób na zrobienie wszystkiego. Odważne stwierdzenie, ale spójrz na to:
ASP.Net MVC:
Witaj, światowa trasa:
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = "" } // Parameter defaults
);Oznacza to, że ASP.Net MVC w jakiś sposób wyszuka HomeControllerTwój kod. W jakiś sposób stwórz jego nową instancję, a następnie wywołaj funkcję Index najwyraźniej z jakimś idparametrem. Są też inne rzeczy:
RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";Są też podobne rzeczy z XAML. DataContextjest traktowany jako przedmiot i musisz mieć nadzieję i modlić się, aby to rozwiązał do pożądanego rodzaju. DependencyProperties musi używać magicznych ciągów i konwencji nazewnictwa magicznego. I takie rzeczy:
MyData myDataObject = new MyData(DateTime.Now);
Binding myBinding = new Binding("MyDataProperty");
myBinding.Source = myDataObject;Chociaż bardziej opiera się na rzucaniu i różnych magicznych mechanizmach uruchomieniowych.
W każdym razie mówię to wszystko, aby tu skończyć: Dlaczego jest to tak dobrze tolerowane w świecie .Net? Czy nie używamy języków o typie statycznym, aby prawie zawsze wiedzieć, jakiego rodzaju rzeczy? Dlaczego odbicie i typ / metoda / właściwość / jakiekolwiek nazwy (jako ciągi znaków) są tak bardzo preferowane w porównaniu do nazw ogólnych i delegatów, a nawet generowania kodu?
Czy istnieją odziedziczone powody, dla których brakuje mi powodu, dla którego składnia routingu ASP.Net opiera się prawie wyłącznie na odbiciu, aby faktycznie rozwiązać sposób obsługi trasy? Nienawidzę, kiedy zmieniam nazwę metody lub właściwości i nagle coś się psuje, ale wydaje się, że nie ma żadnych odniesień do tej metody lub właściwości i oczywiście nie ma błędów kompilatora. Dlaczego widoczną wygodę magicznych ciągów uważano za „tego wartą”?
Wiem, że istnieją również statycznie typowane alternatywy dla niektórych rzeczy, ale zwykle zajmują miejsce na drugim końcu i wydaje się, że nigdy nie są w tutorialach ani innych materiałach dla początkujących.
źródło
var.Odpowiedzi:
W rzeczywistości w świecie .NET istnieje odepchnięcie od tych rzeczy, o których wspomniałeś. Jednak w pierwszym podanym przykładzie silnik routingu otrzymuje konwencję mapowania domyślnej trasy. Sam fakt, że trasy są dynamiczne, uniemożliwia użycie konfiguracji statycznej.
Wspominasz także o XAML / WPF, które były w fazie rozwoju na długo przed wprowadzeniem generycznych do .NET, a powrót do obsługi generycznych opóźniłby już bardzo późny produkt (Longhorn / Vista).
Istnieją przykłady w ramach ASP.NET MVC użycia wyrażeń lambda zamiast magicznych ciągów, a Entity Framework / LINQ posuwa to jeszcze dalej, gdzie język i struktura zapewniają natywną obsługę tworzenia zapytań SQL na statycznym wykresie obiektowym (zamiast konstruowania magiczne ciągi SQL, otrzymasz sprawdzanie poprawności zapytań w czasie kompilacji).
Aby zapoznać się z innymi przykładami konfiguracji statycznej, zobacz mapę struktury i inne nowoczesne kontenery wstrzykiwania zależności oraz inne struktury, które muszą sprawdzać wykres obiektów w czasie wykonywania, ale pozwalają programistom na statyczne dostarczanie wskazówek przy użyciu wyrażeń lambda.
Krótka odpowiedź brzmi, że historycznie .NET nie obsługiwał statycznego przechodzenia wykresu obiektowego do czasu wydania 3.5. Teraz, gdy go mamy, wielu programistów woli go od magicznych ciągów, a wielu dąży do jeszcze głębszego wsparcia, takiego jak operator symbolOf, który działa podobnie do operatora typeOf.
źródło