Updating a Classic

This week I went searching for a classic ASP.NET MVC example that I could use as a basis for making further modifications in future articles. I found an old example Movie Database Application from 2009 that I decided to use. Its features include listing movies from a database, creating new movie entries, and editing existing movie entries. Admittedly, it is not a full-featured application, but it does at least give one a starting point to try to understand how to accomplish some simple goals quickly using ASP.NET MVC.

As I mentioned, the article was written in 2009, so there have been a lot of changes since then. The screenshots were taken using Visual Studio 2008. I decided to refresh the example, using Visual Studio 2015 and ASP.NET MVC 5. Given the release date of the article, it appears that the article was written using ASP.NET MVC 1.0.

The purpose of this article is to share my updated version of this classic example and to discuss a few of the differences that I encountered in recreating it with ASP.NET MVC 5. Although the differences were not extensive, they would be enough to trip up a novice trying to follow along at this point. Granted, there are likely plenty of other newer examples, but I felt like this simple example was a good fit for my planned usage in future articles.

First, you would now use one of the Visual Studio Community versions. 2017 is the newest, but I already had 2015 installed, so I went with that. The feature set of these free versions is quite impressive given the bargain price tag. Given that you would be using a different version of Visual Studio, many of the dialogs are slightly different. However, the differences are quite minor considering that nearly ten years has passed.

Second, creating an Entity Framework (EF) data model has changed slightly, but again the change is very minor. The thing that stood out to me was the fact that EF6 is now trying to come up with appropriate singular names for the objects based upon the plural naming of the database table. In my case, it tried to rename the Movies table to Movy. This update would probably work for a number of different nouns, so it’s understandable why they took that approach.

Third, the generated views now use Razor instead of ASPX. I am of a similar opinion to a lot of developers that Razor is easier to work with, so this is a bonus. Razor became the default view engine with ASP.NET MVC 3, so it makes sense that this would now be the case. Although these views like a fair amount different from those given in the example, they are all generated, so the impact on creating the project is virtually none.

Finally, the biggest difference that I found in this example was that the EF editing code needed to be updated to work with EF6. Some of the methods called in the example, such as ObjectContext.ApplyPropertyChanges, are no longer available. I had to end up replacing the code for adding records to the database and updating records in the database.

Below is the controller method that I used to handle creating a movie record in the database. This includes the updated EF methods necessary to make this work with EF6.

The following is the controller method that I used to handle updating a movie record in the database. Again, this includes updated EF methods needed to make this work with EF6.

All in all, the process of getting this classic example running with ASP.NET MVC5 in Visual Studio 2015 was accomplished with little difficulties. I consider this to be somewhat impressive, given that the example is nearly ten years old. I will be using this refreshed version of the example in some future articles to demonstrate various features of ASP.NET MVC.

 

Third Party View Engines R.I.P?

After finishing my recent overview of ASP.NET MVC view engines, I thought that I would take a deeper look at a specific third party view engine implementation. The users of Stack Overflow have provided a good list of available view engines. I took a brief look at the web sites for all of the view engines, and one thing that really stuck out at me was the fact that none of them had been updated for quite some time.

Despite this, I decided that I would experiment one of them, and chose NHaml. Based on the Rails Haml view engine, NHaml sounds intriguing to me. It takes a different approach than most by abstracting away the HTML markup language.

I saw that a NuGet package was available for NHaml, so i figured that chances for getting it running were promising. Unfortunately, after fiddling around with it for a while, I did not have good luck getting it running under MVC5. I managed to get around the initial error with the NuGet package (Derived types must either match the security accessibility of the base type or be less accessible) by downloading the source code and removing the “AllowPartiallyTrustedCallers” attribute from the SharedAssemblyInfo.cs in the System.Web.NHaml project. However, I then found myself running into access denied errors as NHaml apparently tries to delete temp files from disk.

Considering that NHaml has not been updated for quite some time, I decided that it wasn’t worth investing anymore time into getting it up and running. I may still take a look at one of the other view engines, just to get a sense for how different it is from Razor.

I do still wonder why there has been no recent action on the third party view engine front. I don’t have any complaints about Razor, but is it really that good that it deserves no well maintained competition other than the ASPX view engine? Apparently, Microsoft has done a good job of meeting the desires of developers with the feature set that they have provided in Razor.

View Engines

ASP.NET MVC is a pluggable framework with many parts that may be replaced or customized. One of these parts is the view engine. View engines assist controllers with transforming views into HTML. The view engine is a part of the ASP.NET MVC pipeline. A detailed diagram of the pipeline can be found at DotNetTricks.

MVC includes support for two default view engines. The ASPX view engine was the default for MVC 1.0 and 2.0. This is the view engine that is used by Web Forms. The Razor view engine became the default starting with MVC 3.0. This view engine leveraged a new syntax that relies heavily on the @ character. Even though the Razor view engine has been the default for more recent versions of MVC, you can still use ASPX, and both are enabled by default for an MVC project. MVC additionally allows you to disable one or both of these default view engines and enable other third party view engines such as Spark and NHaml.

You can create your own custom view engine, which is a powerful feature offered by MVC. There are three main components necessary for this: a class that implements IViewEngine, a class that implements IView, and views that leverage your custom view engine markup. After doing all of this, you will need to add your view engine (the class that implements IViewEngine) to the list of view engines in the Application_Start method of Global.asax.cs. When experimenting with view engines, I followed along with a fine example from Code Project.

When creating a class that implements IViewEngine, you can inherit from the VirtualPathProviderViewEngine, which provides some of the default behavior for you. One of the key things that you will want to accomplish with this class is to specify the location of your views. If you will still be using one or both of the default view engines alongside your custom view engine, you will need to be careful to specify a unique location or different file extension for your custom views, so that they will not be mistaken for Razor or ASPX views. Below is an example of how to specify the view location within the constructor of the class implementing IViewEngine. It searches for templates in the default location, but with the .tmpl extension.

The class that implements IView is where a lot of the action takes place. It is here that you will need to provide your special template parsing logic. The job of this code will be to find a given markup and replace it with something else. In my case, I was looking for markup like “<TMPL_VAR NAME=Message>” and replacing it with the “Message” value within ViewData. I replaced the Parse method from the Code Project example with the following.

You will of course be providing a number of views that match the format that your IView class is looking for. Below is an example of what I did in my view while experimenting with view engines. This is a very rudimentary example, but it did serve to demonstrate how to implement a custom view engine.

Why would you want to use a custom view engine? Based on the search results that I found, the most frequent reason that people seem to use a custom view engine is to provide different locations to look for views. Basically, they are wanting to organize their file structure differently than the default. Another reason that you might want to implement a custom view engine is if you are particularly fond of a templating engine used in another language and you want to implement your own version for ASP.NET. This is essentially what I was doing for my example. Before working with .NET, I came from a Perl background. The examples above were the beginnings of implementing a view engine that mimiced the functionality of Perl’s HTML::Template templating engine. Implementing a templating engine from another language could be useful if you have a lot of developers that are not familiar with Razor, but are familiar with another templating engine. However, there may be a price to pay when bringing new .NET developers onboard who are already familiar with Razor. Perhaps a more likely scenario for implementing your own view engine would be to provide some functionality that makes you more productive or does something that Razor cannot do.

Regardless of your motives, one must admit that it is impressive that Microsoft offers the opportunity to customizing this aspect of the pipeline. It provides one with a great deal of power and flexibility. Although I don’t know how useful this feature will be in my own future projects, I am curious to take a peek at some of the other view engines to see how they compare and contrast to the default view engines.

What is MVC?

ASP.NET MVC is an ASP.NET web application framework that saw its first full release in March of 2009. At the time of its release, Web Forms had the majority of the ASP.NET framework sharehold. While I could not find statistics regarding the current usage of the two, the consensus opinion seems to be that MVC has far surpassed the popularity of that older framework at this point. However, Microsoft has clearly stated that MVC is not meant as a replacement for Web Forms.

ASP.NET MVC finds its roots in the MVC architectural pattern. This pattern was devised by Trygve Reenskaug back in 1978, while he was working with Smalltalk-76 at the Xerox Palo Alto Research Center. Its purpose was to correspond the user’s concept of a model to the computers representation of a model. It makes the user think that they are working on their mental model directly and also gives them the opportunity to look at that model using different perspectives (views). This pattern has morphed into a number of variants, including MVP and MVVM. Not only that, but web frameworks leveraging the MVC pattern have taken over a large market share of web applications as a whole. It is doubtful that Reenskaug could have envisioned the level of success that this pattern has achieved.

There are three aspects that make up MVC. These are the model, the view, and the controller. ASP.NET MVC has a strong notion of each of these three components, making it easy for the developer to separate concerns while constructing their application.

The model includes the objects that make up the problem domain of the application. A banking application may include models for an account, a transaction, and a customer. The model can respond to inquiries to retrieve data from its state and requests to change its state. In ASP.NET MVC, a plain old C# class is typically used for a model.

The view comprises the UI components of an application. Separating views allows one to easily devise multiple views for a given model. An example of different views for the same model would be a bar chart view and a tabular data view. In ASP.NET MVC, the views are often realized as Razor View Pages.

The controller is the interface between the view and the model. It handles user interactions, retrieves data from the model, and passes updated data to the model. In ASP.NET MVC, we have controller classes that actualize this component.

The advantages of using the MVC pattern are numerous. One advantage is that each of the three components can be independently worked on by different developers without fear of conflicts. Another benefit is that each layer can be tested more easily than with other architectural approaches. For example, you can test the controllers independently of the views. Finally, the pattern lends itself to allowing for code reuse across applications.

With a large number of existing applications leveraging the MVC pattern and Microsoft continuing to back it with ASP.NET Core MVC 2.0, the future has never looked brighter for MVC. If you haven’t already jumped on the MVC bandwagon, now is a great time to start. With the new promise of cross platform compatibility, ASP.NET Core MVC will help your web application reach audiences that you could only have previously dreamed of.