ASP.NET MVC 3.0 - Why strong typing of a model in a view if static compilation does not occur?

Question

I am actively developing desktop applications, local and network services, some classic ASP.NET, etc., so I use static compilation and static code analysis. Now, when I (finally) learn ASP.NET MVC 3.0 , I see that many of the ASP.NET MVC experts and experienced developers recommend using strongly typed views in ASP.NET MVC 3.0 (where applicable).

I assume that "strongly typed" means the @model=... entry at the top of the view code. But at the same time I get IntelliSense for work, static code verification is not performed. I can write everything I want in the @model instruction in cshtml and it will compile and run. Accordingly, Model.Anything also compiled. In fact, if I do not find @model, I can dynamically use any model that I need that has “compatible” properties and methods.

I'm used to the "strongly typed" value of "will not compile", for example LINQ, to the fact that it simply will not compile if you do not get the properties correctly. Is there any other purpose for @model besides IntelliSense, and a runtime error, and why is it called strongly typed if it is, in fact, and not?

Strong typing, Meaning in computer literature

Answer 1

Views are compiled at runtime by default. You can modify the project file (csproj) to compile the views when creating the application by setting the following property:

 <MvcBuildViews>true</MvcBuildViews> 

The disadvantage of this approach is that your build time will increase significantly. You should consider setting this option to true for releases.

You can edit the project file by unloading the project, right-click the project and select "Edit Project"

Answer 2

You can customize your project to include views in your compilation. This will be useful for static typing. Another place will be at runtime, if you try to pass a model that does not match the expected model, you will immediately get an exception. If you dynamically entered views, you would not know that your model is not valid until your view tries to access the property of the model and finds that it is not there.

The second scenario is also a nightmare if you pass the wrong model object, but it has the same named properties as the expected model. Then you get invalid data, and debugging becomes hell.

Answer 3

Model

is a new dynamic type in .net 4.0, so these types are resolved at run time not at compile time.