Чому, здається, .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, ви отримуєте перевірку часу компіляції ваших запитів).

Для інших прикладів статичної конфігурації див. Структурну карту та інші сучасні контейнери для ін'єкцій залежностей та інші рамки, які потребують перевірки графіка об'єкта під час виконання, але дозволяють розробнику статично надавати підказки, використовуючи лямбда-вирази.

Отже, коротка відповідь полягає в тому, що історично .NET не підтримував статичну обхідну графіку об'єкта до версії 3.5. Тепер, коли ми її маємо, багато розробників віддають перевагу їй над магічними рядками, і багато хто наполягає на ще глибшій підтримці, наприклад оператора symbolOf, який працює аналогічно оператору typeOf.