ASP.NET MVC 3.0. Зачем строго типизировать модель в представлении, если статическая компиляция не выполняется?

Я активно разрабатываю настольные приложения, локальные и сетевые сервисы, какой-то классический ASP.NET и т.д., поэтому привык к статической компиляции и статическому анализу кода. Теперь, когда я (наконец-то) изучаю ASP.NET MVC 3.0, я видя, что многие эксперты ASP.NET MVC и опытные разработчики рекомендуют использовать строго типизированные представления в ASP.NET MVC 3.0 (где это применимо).

Я предполагаю, что "строгая типизация" означает запись @model=... в верхней части кода представления. Но при этом я заставляю работать только IntelliSense, статическая проверка кода не выполняется. Я могу написать все, что захочу, в операторе @model в cshtml, и он будет скомпилирован и бегать. Следовательно, Model.Anything также компилируется. На самом деле, если я не набираю @model, я могу динамически использовать любую модель, которая мне нужна, которая имеет «совместимые» свойства и методы.

Я привык к «строго типизированному», что означает «не будет компилироваться», например, LINQ to что угодно просто не скомпилируется, если вы не укажете свойства правильно. Есть ли у @model какая-либо другая цель, кроме IntelliSense и ошибка времени выполнения, и почему она называется строго типизированной, если на самом деле это не так?

Строгая типизация, Значения в компьютерной литературе


asp.net-mvc-3 type-safety strong-typing strongly-typed-view
person Boris B.    schedule 06.06.2011    source источник
comment
возможный дубликат stackoverflow.com/questions/383192 /compile-views-in-asp-net-mvc   -  person Eranga    schedule 06.06.2011
comment
Хотя мой вопрос определенно не дублирует тот, который вы указали, фактический ответ может быть полезен.   -  person Boris B.    schedule 06.06.2011
comment
Эранга фактически указал на потенциальный ответ на то, о чем вы просите. Насколько я могу судить, вам нужна проверка представлений Razor во время компиляции. По ссылке показано, как это настроить.   -  person Khepri    schedule 06.06.2011
comment
@Eranga, да, это то, что я сказал в первом комментарии, что ответ на вопрос может быть применим. :)   -  person Boris B.    schedule 06.06.2011

Ответы (3)


arrow_upward
3
arrow_downward

По умолчанию представления компилируются во время выполнения. Вы можете изменить файл проекта (csproj) для компиляции представлений при сборке приложения, установив следующее свойство:

<MvcBuildViews>true</MvcBuildViews>

Недостатком этого подхода является то, что время сборки значительно увеличится. Вам следует установить для этого параметра значение true только для выпускных сборок.

Вы можете отредактировать файл проекта, выгрузив проект, щелкнув проект правой кнопкой мыши и выбрав «Редактировать файл проекта».

person Robin van der Knaap    schedule 30.06.2011
comment
Кажется, что если мое представление имеет @model IEnumerable<MyProject.Models.Foo> и я вызываю это представление в контроллере, используя return View("TheView", new int[] { 1, 2, 3 }), проект компилируется без ошибок, даже если MvcBuildViews имеет значение «true» в файле .csproj. - person Simon Shine; 12.08.2015

arrow_upward
0
arrow_downward

Можно настроить ваш проект так, чтобы он включал представления в вашу компиляцию. Вот где статическая типизация полезна. Другое место было бы во время выполнения, если вы попытаетесь передать модель, которая не соответствует ожидаемой модели, вы немедленно получите исключение. Если бы вы вводили представления динамически, вы бы не знали, что ваша модель недействительна, пока ваше представление не попытается получить доступ к свойству модели и не обнаружит, что его там нет.

Второй сценарий также является кошмаром, если вы передаете неправильный объект модели, но он имеет то же именованное свойство, что и ожидаемая модель. Тогда вы просто получите неверные данные, и отладка превратится в ад.

person Chev    schedule 06.06.2011

arrow_upward
0
arrow_downward

model — это новый динамический тип в .net 4.0, поэтому эти типы разрешаются во время выполнения, а не во время компиляции.

person prakash    schedule 26.06.2011