Почему мир .Net, кажется, заключает в себе магические строки вместо статически типизированных альтернатив?

Итак, я работаю в .Net. Я делаю проекты с открытым исходным кодом в .Net. Одна из моих самых больших проблем с этим связана не с .Net, а с сообществом и структурами вокруг него. Повсюду кажется, что магические схемы именования и строки рассматриваются как лучший способ сделать все. Смелое утверждение, но посмотрите на это:

ASP.Net MVC:

Привет мир маршрут:

        routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );

Это означает, что ASP.Net MVC будет как-то искать HomeControllerв вашем коде. Каким-то образом создайте его новый экземпляр, а затем вызовите функцию, Index очевидно, с idкаким-то параметром. И тогда есть другие вещи, как:

RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";

И затем, с XAML есть похожие вещи. DataContextрассматривается как объект, и вы должны надеяться и молиться, чтобы он соответствовал тому типу, который вы хотите. DependencyProperties должен использовать магические строки и соглашения о магическом именовании. И такие вещи:

  MyData myDataObject = new MyData(DateTime.Now);      
  Binding myBinding = new Binding("MyDataProperty");
  myBinding.Source = myDataObject;

Хотя он больше полагается на кастинг и различные магические поддержки во время выполнения.

Во всяком случае, я говорю все это, чтобы закончить здесь: почему это так хорошо переносится в мире .Net? Разве мы не используем статически типизированные языки, чтобы почти всегда знать, что это за вещи? Почему рефлексия и тип / метод / свойство / любые имена (как строки) так предпочтительны по сравнению с обобщениями и делегатами или даже генерацией кода?

Существуют ли унаследованные причины, по которым мне не хватает того, почему синтаксис маршрутизации ASP.Net полагается почти исключительно на рефлексию, чтобы фактически решить, как обрабатывать маршрут? Я ненавижу, когда я изменяю имя метода или свойства и вдруг что-то ломается, но, похоже, нет никаких ссылок на этот метод или свойство, и, конечно, нет ошибок компилятора. Почему очевидное удобство волшебных струн считалось «стоящим»?

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

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

Вы также упоминаете XAML / WPF, оба из которых разрабатывались задолго до того, как дженерики были введены в .NET, и возвращение к поддержке дженериков задержало бы уже очень поздний продукт (Longhorn / Vista) еще больше.

В рамках ASP.NET MVC есть примеры использования лямбда-выражений вместо магических строк, и Entity Framework / LINQ продвигает это еще дальше, когда язык и инфраструктура предоставляют встроенную поддержку для составления запросов SQL через статический граф объектов (вместо создания Волшебные строки SQL, вы получите проверку времени выполнения ваших запросов).

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

Таким образом, краткий ответ заключается в том, что исторически .NET не поддерживал статический обход графа объектов до выпуска 3.5. Теперь, когда он у нас есть, многие разработчики предпочитают его магическим строкам, и многие стремятся к еще более глубокой поддержке, такой как оператор symbolOf, который работает аналогично оператору typeOf.