Thursday, April 9, 2020

What is Entity Framework Core

Entity Framework is an Object/Relational Mapping (O/RM) framework. It is an enhancement to ADO.NET that gives developers an automated mechanism for accessing & storing the data in the database. EF Core is intended to be used with. NET Core applications. However, it can also be used with standard

Entity Framework (EF) Core is a lightweight, extensible, open-source and cross-platform version of the popular Entity Framework data access technology.

EF Core can serve as an object-relational mapper (O/RM), enabling .NET developers to work with a database using .NET objects, and eliminating the need for most of the data-access code they usually need to write.

Sunday, April 27, 2014

AngularJS Vs EmberJS



AngularJS Vs EmberJS

One of the battles we are seeing the developers fight these days has been for the Throne of JS framework. The interwebs keep fighting these wars and in the end there is never a proper victor. But still we persevere because that is the nature of humans. The contenders in this particular war are Backbone, Ember & Angular ( there are other smaller colonies but for this discussion and for the sake of brevity we shall leave them out ). . Alteast, these are the 3 most popular MV* javascript client-side frameworks according to github watchers.

This post is not mostly about Backbone because a lot of people have already discussed it at length, come to various conclusions and moved on. Even the inspiration for this blogpost compares Backbone with Ember. I myself have written a longish answer on StackOverflow about the topic.

Disclaimer : I have never worked with EmberJS. So you might deem that I am not the proper person to talk about this. Continue at your own risk.

This post is really a response to what the inspiration talks about. This is a response based on what I managed to assimilate based on that post. So lets begin…

Backbone and Ember

To set things straight first, after having gone through that post, one thing was clear to me. Ember apparently does , in fact, do more ( much, much more! ) than what Backbone does for any developer. One of the toughest things to do, when starting a project, is making choices. Ember takes care of that for you. It has already made choices and it has already prescribed those choices to you, which means that there is “an Ember way” of doing things. You stray from this god-chosen path and you are left to yourself.

Backbone on the other hand does not make any choices for you which means that you have freedom to choose. Freedom means that you are in fact wasting quite a lot of time making these choices yourself ( and in the end taking responsibility for those choices ). One thing we have to remember is, the average developer out there is like a sheep. He will never know the boundaries of the grazing field. This means that giving him more freedom will eventually lead to him going astray and never knowing that he actually did. Even in restricted environments, you can do mistakes but lets just say that the chances are less. You would argue that , if there is a lot of freedom, the average developer will be more careful. Yes, he would be when he has infinite time and not when there is a manager behind his back pointing a gun to his head. So, restrictions are good. In fact, they are a blessing. Atleast now you can blame the framework.

Does Backbone have two way data binding? No. Ember does.

Does Backbone have composed views? No. Ember does. In fact backbone has no idea about your DOM. You are left on your own when it comes to DOM.

Does Backbone have a complex model structure ? No. Its model structure is the simplest possible. Its “observe” mechanism arises out of setters and getters that are defined on the base Backbone Model Class. Ember does have a mechanism for declaring complex model structures. It has a totally separate module (Ember Data ) to take care of that.

So far we have established that Ember is in fact a far superior choice to Backbone. Now lets try and take apart Ember, shall we?

Language

Ember is / has been put together with a lot of thought behind it. One of the major things that I noticed when going through trek’s post was that Ember used concepts like Ember.Object.extend(…). If you notice what is being done here, you will understand that we are trying to bring into a language a concept that it refuses to bring in. A class. In fact it explicitly calls it a class ( Note the use of reopenClass ).

As opposed to this, angular uses a concept that defines javascript. Its prototype chain. It uses a $scope and each scope you create, prototypically inherits from its parent scope all the way upto the RootScope. Most of your activity is done on this object. There is no confusion regarding “this” because you dont really have to use it in most cases.

Data-binding and polluting the views

This is one of the most infamous complaints I have heard of in terms of what Angular / Knockout do to the HTML. In the name of 2 way data binding, they pollute the beauty, the sanctity of HTML and add their own shit in between. In terms of templating systems, there are two kinds. DOM templates and String Templates. These string templates take strings , take the data and combine them together and produce a pure html which is then pushed into the DOM. To those who talk about the pureness and sanctity of HTML / views, I have a few questions. Why the f**k do you really care about it? What you should be caring about is your productivity and how it looks / appears to your user. Lets say you do have some valid reasons. Have you had a look at the code you have to write to produce these templates in handlebars, mustache, underscore or jqtemplates? They are all ugly as shit and even worse. Just to add, computed properties do exist in Angular as well.

Composite Views

How do both the frameworks compare in terms of Composing views and nesting views inside of each other. As far as my understanding goes, Ember has a way of defining these using outlets (with names if you need multiple ). In your handlebars templates you define outlets which can further be installed into the current view as and when required. Swapping and replacing of these outlets is the way to go if you are into Ember. Angular, since it does everything with HTML itself and calls itself Enhanced HTML provides you more attributes that are self-explanatory. If you see an attribute called ng-switch or ng-repeat what comes to your mind? Yeah, you are right. They both are responsible for exactly what you thought.

This is how you define a repeated element in handlebars / ember<code>&lt;script type="text/x-handlebars" data-template-name="contributors"&gt; {{#each person in controller}} {{person.login}} {{/each}} &lt;/script&gt;</code>

This is how you do the same thing in angular

<code>&lt;span ng-repeat="person in persons"&gt;{{person.login}}&lt;/span&gt;</code>


Which do you think is cleaner? Ofcourse, in the final rendered html the ember way above is going to look cleaner because all the other stuff is going to get stripped out. In case of angular, all of this (except the thing in double flower brackets ) is going to stay. But, seriously, who is having a look at your final rendered HTML? Just so you know, that who script tag is going to still exist in your final HTML too , but somewhere else.

DOM Manipulation / the ugly part of client side coding

Whether you agree or not, manipulating the DOM is the most ugly part of writing code in JS. By now most of us are so used to it that it has become part of our life, part of the way of our thinking about DOM. Ofcourse, just to encourage you not to do it, IE / M$ had put in all kind of hurdles in front of you and earlier not many tried crossing that barrier. Finally, one day a great leader ( JQuery ) came forward and showed you a way of crossing the sea ( They even parted that sea for you so you can cross) you are now so accustomed to this life across the sea. What if I told you that you can achieve all the things you have been achieving after getting access to these new tools WITHOUT using them? Ofcourse, you still need those new resource. But, use it only when its absolutely necessary. Not everytime.

Component Architechture.

Ember does not provide you a component architecture. It does not provide you a way of defining new components. It helps you define views , even composite ones but that is not one and the same. Angular’s directive mechanism though agreeably raw currently allows you to provide powerful layouts and widgets. This provides a mechanism for defining terse html code that makes more sense to the reader. It also makes it easier to partition tasks. You can have a component writer and a layout builder – 2 different people doing different tasks they have expertise with. We could even have an open source project which provides you those controls out of the box which anyone can plugin (just like jquery plugin’s but this one is used declaratively! ).

Dependancy Injection

This is something new in the world of JS. As far as I can tell, not many ( I don't know of one that has DI ) have implemented DI in JS. I will be bold enough to declare that Angular is probably one of the only mainstream framework to implement DI. I am not even going to talk about DI in Ember because it doesn't seem to exist. Those who are new to this system seem to find this to be totally absurd or magic. How can it work? Do we declare everything as global and then input those global variables into these controller functions for the heck of it? Apparently not.

DI makes it extremely easy to manage dependancies. There is a central system (which perhaps is global) that when asked for an object of a particular type gives you that object. What do you do in a typical scenario of OOP. If A has a dependency on B, you try to figure out what is the best way of getting B into A. Sometimes you do that communication through events, sometimes through an interface etc. In DI , A asks the DI system for B and the DI system gives it back. But now the question is ,how does the DI system know what to give back? This is done when A or B is created. They register themselves with the DI system with a Unique Name. Lets say DI has an internal map which has a mapping between the name and the Object / Class to instantiate. So whenever you do a DI.give(“A”) it instantiates this A and gives you back that A.

Conclusion

In Conclusion, it looks like Angular provides you with whatever Ember is providing and more. It also has a smaller footprint ( 25kb vs 37kb), reduces even more boilerplate than what Ember does ( remove all DOM Manipulations!). Just to note: Ember is not done yet because they haven't hit 1.0 yet. So we still need to know how they evolve. But it looks like it was created for large applications and helps manage more things than Backbone does, I would even call it an opinionated Backbone on steroids but I don't see it touching the levels of Angular. I don't say this out of malice towards Ember but because angular is showing itself to be a class apart. It dared to think differently and that paid off.

Angular JS and Knockout JS



KnockoutJS vs AngularJS 

Luckily (or unluckily ? ), I keep getting opportunities to work with everything other than Angular. In my latest assignment, I have had the opportunity to work with Knockout. I have to say that I liked it and would have picked Knockout as my favorite framework if Angular did not exist.

People keep asking these questions and probably there is a good reason for it. Humans hate choices. If there are resources out there which help them make these choices easier, they like it. So, if you havent already tried the two frameworks, here are some comparisons/differences betwen the two.

Templating

Angular and Knockout both provide DOM based templating.

Angular only supports HTML as its templating mechanism.

Knockout by default uses HTML as its templating mechanism ( which is where they both have DOM based templating ) , but Knockout also supports other string based templating engines like Handlebars etc (but I think hardly anyone uses that!).

Unobtrusive

Knockout tries to please people who are interested in Unobtrusive Stuff.. http://knockoutjs.com/documentation/unobtrusive-event-handling.html

Angular doesnt believe in it ( or the authors of angular do not make any exceptions to provide for unobtrusive cases. )

Context

In knockout, in order to fetch data from a context that is in the parent of your current context, you need to access it using `$parent`.

In angular, context’s inherit prototypically. So, to access something from the parent context, you dont usually have to use $parent . You only need to use $parent if you have another variable with the same name defined in your current context as well.

Directives or Custom Bindings

Angular has directives. You can define custom elements, custom attributes, comments and classes.

Knockout doesnt allow you to create custom elements. You have to create all your bindings inside data-bind. ( I am not sure about this. Someone can correct me if I am wrong! ).

JQuery Dependency

Angular has its own version of JQuery called JQueryLite ( smaller jquery). If you include JQuery before Angular, it will use the JQuery you loaded.

Knockout does not depend on JQuery or create its own version of it. But, having said that, Knockout is a data-binding library. It does not have any opinions or implementations for doing Ajax or DOM querying. If you don’t include JQuery, you are free to do ajax and DOM manipulation either directly or with some other library.

Partitioning or creating new contexts

Angular has a concept of controllers which allow you to create new contexts explicitly. Angular also implicitly creates context’s when using ng-repeat, ng-switch, ng-include etc. Angular’s controllers, services and its concept of DI make it extremely easy to partition and manage large applications.

Knockout doesnt allow you to create contexts explicitly (Unless you create custom bindings). Knockout implicitly creates new contexts when using for-each etc.. This also means that Knockout has no opinion regarding the overall structure of your application. Without careful planning its easy to “mess up” your code base with Knockout.

Browser support

Angular supports all new browsers and its support goes back till IE8.

Knockout supports till IE6.

Batteries included

Angular is a full fledged framework. It provides dependency injection, ajax, routing, cookies, promises and much more.. Angular is great for testing.

Knockout is a data-binding library. To go for a full fledged framework have a look at DurandalJS – which is a combination of Knockout, JQuery and RequireJS. Knockout was not built with testing in mind. So, it doesnt score soo many points in that department. But still, I think it wont be terrible.

Documentation

Angular documentation covers pretty much everything it has. Angular is huge.. Its a shift in paradigm.. in the way of thinking itself. So, no matter how much documentation you have ( and we dont have enough ! ) you will always want more.. Certain core pieces are missing from the documentation.

Knockout’s documentation is the most praised in the community. But… ( yes, there is a but! )… Knockouts documentation for all the binding syntax is amazing, extensive.. But, when it comes to the utilities that knockout provides, there is zilch.. No where can you find documentation for those.. Either the documentation doesn’t exist or it is in such an obscure place that its hard to find.

IDE support and debugging support

Angular has amazing plugins available for all Intellij IDE’s. There is also a plugin available for Visual studio, which I believe is a port of the Intellij plugin. Angular also has a Google Chrome extension called Angular Batarang which allows you to select any element in the developer tools window and preview its scope variables.

Knockout doesnt have any popular IDE plugins which help in developer productivity.. I believe it is mostly because it used a single data-* attribute as opposed to Angular which uses different data-* attributes for different tasks. In terms of plugins, Knockout too has a Google Chrome extension, but I am not sure it works as seamlessly as the Angular Batarang. I tried it, did not work very well for my use cases, so I dropped it.

If you want to debug knockout in your browser, here is a tip (Google Chrome):F12 ( Open developer tools ) Select / Click on the element you want to inspect.

Open the console.

The current highlighted element is available in the console as $0

In the console, typevar context = ko.contextFor($0); context

context will now have your context information for that element. This context will give you ideas of what and how you could use it in the data-bind attribute.

Community Support

Ok, this is going to be controversial. But, I believe this is based on facts. So here it is.

Angular has a bigger community. No doubts about it. If you ask a question, there is a high probability you will get an answer.

Knockout has a comparatively much smaller community.

For me the measure of an open source projects community is a function of 3 things.

1. Github stars and forks

2. Stack Overflow questions

3. Google groups – number of posts per week and number of members.

Angular wins hands down in 1 and 2. In SO questions category, they are very close.

Ease

You should understand that Angular is a full fledged framework while Knockout is a data-binding library. There are way too many concepts in Angular and it forces you into a totally different way of thinking. This is not easy.

Learning knockout is easy. The simple things atleast. I think one of the problems with Knockout is that there aren’t many articles / blogs about it. Not in the 100′s atleast. If you need to do something obscure, you are on your own. Ofcourse asking about it on SO will help. The same is also true about Angular. But, there is a subtle difference. Angular is meant for these obscure things.. custom bindings etc.. So , over time you will find more and more documentation and blogs for it. All over the world wide web, if you look for Angular, you will see people talking about directives.. which are custom bindings.. Not the same case with custom bindings in Knockout. I am sure people use it, but they just dont talk about it much.

Variable Observation

Angular observes variables using a technique called as dirty checking. On the other hand, Knockout uses the Observable pattern. In terms of code

Angular HTML :

1 <div ng-bind="myContent"></div>
or
1
<div>{{myContent}}</div>
Angular javascript :
1 $scope.myContent = "Hello World";
Knockout HTML :
1 <div data-bind="text : myContent"></div>
Knockout Javascript :
var myContent = ko.observable("Hello World");
To change this content..
In Angular :
$scope.myContent = "Hello You";
In Knockout :
myContent("Hello You")
Events and custom parameter passing :

Angular HTML
<button data-ng-click="onButtonClick($event,'save')">Save</button>


<button data-ng-click="onButtonClick($event,'cancel')">Cancel</button>

Angular Javascript
$scope.onButtonClick = function(event,action){
// your code.
};
Knockout HTML
<button data-bind="click : onButtonClick.bind($root,'save')">Save</button>
<button data-bind="click : onButtonClick.bind($root,'cancel')">Cancel</button>
or
<button data-bind="click: function(data, event) { onButtonClick('save',data, event) }">Save</button>
<button data-bind="click: function(data, event) { onButtonClick('cancel',data, event) }">Cancel</button>

Conclusion

I love similes and metaphor’s. In my Angular vs Backbone post, I said that if Angular could be consider a Motor Boat with all its complexities in machinery and mechanism, Backbone could be compared to a Life Jacket. Backbone forces you not to drown, which is why it was compared to a Life Jacket. Knockout’s focus isnt about your drowning. It is about your speed which is why it doesn’t care whether you drown or not. Images are better than words.. So here is the comparison.

Monday, January 6, 2014

Session 2 - HTML Helper (Tag)

www.dotnetstory.comHTML Helpers (MVC3)

The goal of this tutorial is to demonstrate how you can create custom HTML Helpers that you can use within your MVC views. By taking advantage of HTML Helpers, you can reduce the amount of tedious typing of HTML tags that you must perform to create a standard HTML page.

In the first part of this tutorial, I describe some of the existing HTML Helpers included with the ASP.NET MVC framework. Next, I describe two methods of creating custom HTML Helpers: I explain how to create custom HTML Helpers by creating a static method and by creating an extension method.
Understanding HTML Helpers
An HTML Helper is just a method that returns a string. The string can represent any type of content that you want. For example, you can use HTML Helpers to render standard HTML tags like HTML <input> and <img> tags. You also can use HTML Helpers to render more complex content such as a tab strip or an HTML table of database data.
The ASP.NET MVC framework includes the following set of standard HTML Helpers (this is not a complete list):
  • Html.ActionLink()
  • Html.BeginForm()
  • Html.CheckBox()
  • Html.DropDownList()
  • Html.EndForm()
  • Html.Hidden()
  • Html.ListBox()
  • Html.Password()
  • Html.RadioButton()
  • Html.TextArea()
  • Html.TextBox()
For example, consider the form in Listing 1. This form is rendered with the help of two of the standard HTML Helpers (see Figure 1). This form uses the Html.BeginForm() and Html.TextBox() Helper methods to render a simple HTML form.
Figure 01: Page rendered with HTML Helpers (Click to view full-size image)
Listing 1 – Views\Home\Index.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Views.Home.Index"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns= "http://www.w3.org/1999/xhtml ">
<head id="Head1" runat="server">
     <title>Index</title>
</head>
<body>
      <div>
          <% using (Html.BeginForm())
          { %>

               <label for="firstName">First Name:</label>
               <br />
               <%= Html.TextBox("firstName")%>
               <br /><br />
               <label for="lastName">Last Name:</label>
               <br />

               <%= Html.TextBox("lastName")%>
               <br /><br />
               <input type="submit" value="Register" />    
          <% } %>
     1     </div>
</body>
</html>
    
The Html.BeginForm() Helper method is used to create the opening and closing HTML <form> tags. Notice that theHtml.BeginForm() method is called within a using statement. The using statement ensures that the <form> tag gets closed at the end of the using block.
If you prefer, instead of creating a using block, you can call the Html.EndForm() Helper method to close the <form>tag. Use whichever approach to creating an opening and closing <form> tag that seems most intuitive to you.
The Html.TextBox() Helper methods are used in Listing 1 to render HTML <input> tags. If you select view source in your browser then you see the HTML source in Listing 2. Notice that the source contains standard HTML tags.
IMPORTANT: notice that the Html.TextBox()-HTML Helper is rendered with <%= %> tags instead of <% %> tags. If you don't include the equal sign, then nothing gets rendered to the browser.
The ASP.NET MVC framework contains a small set of helpers. Most likely, you will need to extend the MVC framework with custom HTML Helpers. In the remainder of this tutorial, you learn two methods of creating custom HTML Helpers.
Listing 2 – Index.aspx Source
<%@ Page Language="C#" AutoEventWireup="false" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Index" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
     <title>Index</title>
</head>
<body>
     <div>
          <form action="http://localhost:33102/" method="post">
               <label for="firstName">First Name:</label>

               <br />
               <input id="firstName" name="firstName" type="text" value="" />
               <br /><br />
               <label for="lastName">Last Name:</label>
               <br />
               <input id="lastName" name="lastName" type="text" value="" />
               <br /><br />

               <input id="btnRegister" name="btnRegister" type="submit" value="Register" />
          </form>
     </div>
</body>
</html>
        

Creating HTML Helpers with Static Methods

The easiest way to create a new HTML Helper is to create a static method that returns a string. Imagine, for example, that you decide to create a new HTML Helper that renders an HTML <label> tag. You can use the class in Listing 2 to render a<label> .
Listing 2 – Helpers\LabelHelper.cs
using System;
namespace MvcApplication1.Helpers
{
          public class LabelHelper

          {
               public static string Label(string target, string text)
               {
                    return String.Format("<label for='{0}'>{1}</label>", target, text);
               }
          }
}
        
There is nothing special about the class in Listing 2. The Label() method simply returns a string.
The modified Index view in Listing 3 uses the LabelHelper to render HTML <label> tags. Notice that the view includes an<%@ imports %> directive that imports the Application1.Helpers namespace.
Listing 2 – Views\Home\Index2.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index2.aspx.cs" Inherits="MvcApplication1.Views.Home.Index2"%>
<%@ Import Namespace="MvcApplication1.Helpers" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">

     <title>Index2</title>
</head>
<body>
     <div>
          <% using (Html.BeginForm())
          { %>
               <%= LabelHelper.Label("firstName", "First Name:") %>
               <br />

               <%= Html.TextBox("firstName")%>
               <br /><br />
               <%= LabelHelper.Label("lastName", "Last Name:") %>
               <br />
               <%= Html.TextBox("lastName")%>
               <br /><br />
               <input type="submit" value="Register" />
          <% } %>

     </div>
</body>
</html>
        

Creating HTML Helpers with Extension Methods

If you want to create HTML Helpers that work just like the standard HTML Helpers included in the ASP.NET MVC framework then you need to create extension methods. Extension methods enable you to add new methods to an existing class. When creating an HTML Helper method, you add new methods to the HtmlHelper class represented by a view's Html property.
The class in Listing 3 adds an extension method to the HtmlHelper class named Label(). There are a couple of things that you should notice about this class. First, notice that the class is a static class. You must define an extension method with a static class.
Second, notice that the first parameter of the Label() method is preceded by the keyword this. The first parameter of an extension method indicates the class that the extension method extends.
Listing 3 – Helpers\LabelExtensions.cs
using System;
using System.Web.Mvc;

namespace MvcApplication1.Helpers
{
     public static class LabelExtensions
     {
          public static string Label(this HtmlHelper helper, string target, string text)
          {
               return String.Format("<label for='{0}'>{1}</label>", target, text);

          }
     }
}
        
After you create an extension method, and build your application successfully, the extension method appears in Visual Studio Intellisense like all of the other methods of a class (see Figure 2). The only difference is that extension methods appear with a special symbol next to them (an icon of a downward arrow).
Using the Html.Label() extension method
Figure 02: Using the Html.Label() extension method (Click to view full-size image)
The modified Index view in Listing 4 uses the Html.Label() extension method to render all of its <label> tags.
Listing 4 – Views\Home\Index3.aspx
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index3.aspx.cs" Inherits="MvcApplication1.Views.Home.Index3" %>

<%@ Import Namespace="MvcApplication1.Helpers" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
     <title>Index3</title>
</head>
<body>
     <div>

          <% using (Html.BeginForm())
          { %>
               <%= Html.Label("firstName", "First Name:") %>    
               <br />
               <%= Html.TextBox("firstName")%>
               <br /><br />
               <%= Html.Label("lastName", "Last Name:") %>    
               <br />
               <%= Html.TextBox("lastName")%>

               <br /><br />
               <input type="submit" value="Register" />
          <% } %>
     </div>
</body>
</html>
        

Summary

In this tutorial, you learned two methods of creating custom HTML Helpers. First, you learned how to create a custom Label() HTML Helper by creating a static method that returns a string. Next, you learned how to create a custom Label() HTML Helper method by creating an extension method on the HtmlHelper class.
In this tutorial, I focused on building an extremely simple HTML Helper method. Realize that an HTML Helper can be as complicated as you want. You can build HTML Helpers that render rich content such as tree views, menus, or tables of database data.
Using the TagBuilder Class to Build HTML Helpers (C#)
Stephen Walther introduces you to a useful utility class in the ASP.NET MVC framework named the TagBuilder class. You can use the TagBuilder class to easily build HTML tags.

The ASP.NET MVC framework includes a useful utility class named the TagBuilder class that you can use when building HTML helpers. The TagBuilder class, as the name of the class suggests, enables you to easily build HTML tags. In this brief tutorial, you are provided with an overview of the TagBuilder class and you learn how to use this class when building a simple HTML helper that renders HTML <img> tags.

Overview of the TagBuilder Class

The TagBuilder class is contained in the System.Web.Mvc namespace. It has five methods:
  • AddCssClass() - Enables you to add a new class=”” attribute to a tag.
  • GenerateId() - Enables you to add an id attribute to a tag. This method automatically replaces periods in the id (by default, periods are replaced by underscores)
  • MergeAttribute() - Enables you to add attributes to a tag. There are multiple overloads of this method.
  • SetInnerText() - Enables you to set the inner text of the tag. The inner text is HTML encode automatically.
  • ToString() - Enables you to render the tag. You can specify whether you want to create a normal tag, a start tag, an end tag, or a self-closing tag.

The TagBuilder class has four important properties:
  • Attributes - Represents all of the attributes of the tag.
  • IdAttributeDotReplacement - Represents the character used by the GenerateId() method to replace periods (the default is an underscore).
  • InnerHTML - Represents the inner contents of the tag. Assigning a string to this property does not HTML encode the string.
  • TagName - Represents the name of the tag.
These methods and properties give you all of the basic methods and properties that you need to build up an HTML tag. You don’t really need to use the TagBuilder class. You could use a StringBuilder class instead. However, the TagBuilder class makes your life a little easier.

Creating an Image HTML Helper

When you create an instance of the TagBuilder class, you pass the name of the tag that you want to build to the TagBuilder constructor. Next, you can call methods like the AddCssClass and MergeAttribute() methods to modify the attributes of the tag. Finally, you call the ToString() method to render the tag.
For example, Listing 1 contains an Image HTML helper. The Image helper is implemented internally with a TagBuilder that represents an HTML <img> tag.
Listing 1 - Helpers\ImageHelper.cs
using System.Web.Mvc;
using System.Web.Routing;

namespace MvcApplication1.Helpers
{
    public static class ImageHelper
    {
        public static string Image(this HtmlHelper helper, string id, string url, string alternateText)
        {
            return Image(helper, id, url, alternateText, null);
        }

        public static string Image(this HtmlHelper helper, string id, string url, string alternateText, object htmlAttributes)
        {
            // Create tag builder
            var builder = new TagBuilder("img");
            
            // Create valid id
            builder.GenerateId(id);

            // Add attributes
            builder.MergeAttribute("src", url);
            builder.MergeAttribute("alt", alternateText);
            builder.MergeAttributes(new RouteValueDictionary(htmlAttributes));

            // Render tag
            return builder.ToString(TagRenderMode.SelfClosing);
        }

    }
}
 
The class in Listing 1 contains two static overloaded methods named Image. When you call the Image() method, you can pass an object which represents a set of HTML attributes or not.
Notice how the TagBuilder.MergeAttribute() method is used to add individual attributes such as the src attribute to the TagBuilder. Notice, furthermore, how the TagBuilder.MergeAttributes() method is used to add a collection of attributes to the TagBuilder. The MergeAttributes() method accepts a Dictionary<string,object> parameter. The The RouteValueDictionary class is used to convert the Object representing the collection of attributes into a Dictionary<string,object>.
After you create the Image helper, you can use the helper in your ASP.NET MVC views just like any of the other standard HTML helpers. The view in Listing 2 uses the Image helper to display the same image of an Xbox twice (see Figure 1). The Image() helper is called both with and without an HTML attribute collection.
Listing 2 - Home\Index.aspx
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
<%@ Import Namespace="MvcApplication1.Helpers" %>

<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">

    <!-- Calling helper without HTML attributes -->
    <%= Html.Image("img1", ResolveUrl("~/Content/XBox.jpg"), "XBox Console") %>


    <!-- Calling helper with HTML attributes -->
    <%= Html.Image("img1", ResolveUrl("~/Content/XBox.jpg"), "XBox Console", new {border="4px"})%>


</asp:Content>
The New Project dialog box
Figure 01: Using the Image helper(Click to view full-size image)
Notice that you must import the namespace associated with the Image helper at the top of the Index.aspx view. The helper is imported with the following directive:
Creating Page Layouts with View Master Pages (C#)
In this tutorial, you learn how to create a common page layout for multiple pages in your application by taking advantage of view master pages. You can use a view master page, for example, to define a two-column page layout and use the two-column layout for all of the pages in your web application.

Creating Page Layouts with View Master Pages

In this tutorial, you learn how to create a common page layout for multiple pages in your application by taking advantage of view master pages. You can use a view master page, for example, to define a two-column page layout and use the two-column layout for all of the pages in your web application.
You also can take advantage of view master pages to share common content across multiple pages in your application. For example, you can place your website logo, navigation links, and banner advertisements in a view master page. That way, every page in your application would display this content automatically.
In this tutorial, you learn how to create a new view master page and create a new view content page based on the master page.

Creating a View Master Page

Let's start by creating a view master page that defines a two-column layout. You add a new view master page to an MVC project by right-clicking the Views\Shared folder, selecting the menu option Add, New Item, and selecting theMVC View Master Page template (see Figure 1).
Adding a view master page
Figure 01: Adding a view master page (Click to view full-size image)
You can create more than one view master page in an application. Each view master page can define a different page layout. For example, you might want certain pages to have a two-column layout and other pages to have a three-column layout.
A view master page looks very much like a standard ASP.NET MVC view. However, unlike a normal view, a view master page contains one or more <asp:ContentPlaceHolder> tags. The <contentplaceholder> tags are used to mark the areas of the master page that can be overridden in an individual content page.
For example, the view master page in Listing 1 defines a two-column layout. It contains two <contentplaceholder>tags. One <ContentPlaceHolder> for each column.
Listing 1 – Views\Shared\Site.master
<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site.Master.cs" Inherits="MvcApplication1.Views.Shared.Main" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
     <title></title>

     <style type="text/css">

     html
     {
           background-color:gray;
     }

     .column
     {
          float:left;
          width:300px;
          border:solid 1px black;
          margin-right:10px;
          padding:5px;
          background-color:white;

          min-height:500px;
     }

     </style>

     <asp:ContentPlaceHolder ID="head" runat="server">
     </asp:ContentPlaceHolder>
</head>
<body>

     <h1>My Website</h1>

     <div class="column">
          <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
          </asp:ContentPlaceHolder>
     </div>
     <div class="column">
          <asp:ContentPlaceHolder ID="ContentPlaceHolder2" runat="server">
          </asp:ContentPlaceHolder>
     </div>

</body>
</html>
        
The body of the view master page in Listing 1 contains two <div> tags that correspond to the two columns. The Cascading Style Sheet column class is applied to both <div> tags. This class is defined in the style sheet declared at the top of the master page. You can preview how the view master page will be rendered by switching to Design view. Click the Design tab at the bottom-left of the source code editor (see Figure 2).
Previewing a master page in the designer
Figure 02: Previewing a master page in the designer (Click to view full-size image)

Creating a View Content Page

After you create a view master page, you can create one or more view content pages based on the view master page. For example, you can create an Index view content page for the Home controller by right-clicking the Views\Home folder, selecting Add, New Item, selecting the MVC View Content Page template, entering the name Index.aspx, and clicking the Add button (see Figure 3).
Adding a view content page
Figure 03: Adding a view content page (Click to view full-size image)
After you click the Add button, a new dialog appears that enables you to select a view master page to associate with the view content page (see Figure 4). You can navigate to the Site.master view master page that we created in the previous section.
Selecting a master page
Figure 04: Selecting a master page (Click to view full-size image)
After you create a new view content page based on the Site.master master page, you get the file in Listing 2.
Listing 2 – Views\Home\Index.aspx
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Views.Home.Index" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder2" runat="server">
</asp:Content>
        
Notice that this view contains a <asp:Content> tag that corresponds to each of the <asp:ContentPlaceHolder>tags in the view master page. Each <asp:Content> tag includes a ContentPlaceHolderID attribute that points to the particular <asp:ContentPlaceHolder> that it overrides.
Notice, furthermore, that the content view page in Listing 2 does not contain any of the normal opening and closing HTML tags. For example, it does not contain the opening and closing <html> or <head> tags. All of the normal opening and closing tags are contained in the view master page.
Any content that you want to display in a view content page must be placed within a <asp:Content> tag. If you place any HTML or other content outside of these tags, then you will get an error when you attempt to view the page.
You don't need to override every <asp:ContentPlaceHolder> tag from a master page in a content view page. You only need to override a <asp:ContentPlaceHolder> tag when you want to replace the tag with particular content.
For example, the modified Index view in Listing 3 contains only two <asp:Content> tags. Each of the<asp:Content> tags includes some text.
Listing 3 – Views\Home\Index.aspx (modified)
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Views.Home.Index" %>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">

     <h1>Content in first column!</h1>

</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderID="ContentPlaceHolder2" runat="server">

     <h1>Content in second column!</h1>

</asp:Content>

        
When the view in Listing 3 is requested, it renders the page in Figure 5. Notice that the view renders a page with two columns. Notice, furthermore, that the content from the view content page is merged with the content from the view master page
The Index view content page
Figure 05: The Index view content page (Click to view full-size image)

Modifying View Master Page Content

One issue that you encounter almost immediately when working with view master pages is the problem of modifying view master page content when different view content pages are requested. For example, you want each page in your web application to have a unique title. However, the title is declared in the view master page and not in the view content page. So, how do you customize the page title for each view content page?
There are two ways that you can modify the title displayed by a view content page. First, you can assign a page title to the title attribute of the <%@ page %> directive declared at the top of a view content page. For example, if you want to assign the page title "Super Great Website" to the Index view, then you can include the following directive at the top of the Index view:
<%@ page title="Super Great Website" language="C#" masterpagefile="~/Views/Shared/Site.Master"
            autoeventwireup="true" codebehind="Index.aspx.cs" inherits="MvcApplication1.Views.Home.Index"%>
When the Index view is rendered to the browser, the desired title appears in the browser title bar:
Browser title bar
There is one important requirement that a master view page must satisfy in order for the title attribute to work. The view master page must contain a <head runat="server"> tag instead of a normal <head> tag for its header. If the<head> tag does not include the runat=”server” attribute then the title won't appear. The default view master page includes the required <head runat="server"> tag.
An alternative approach to modifying master page content from an individual view content page is to wrap the region that you want to modify in a <asp:ContentPlaceHolder> tag. For example, imagine that you want to change not only the title, but also the meta tags, rendered by a master view page. The master view page in Listing 4 contains a <asp:ContentPlaceHolder> tag within its <head> tag.
Listing 4 – Views\Shared\Site2.master
<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site2.Master.cs" Inherits="MvcApplication1.Views.Shared.Site2" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>

     <asp:ContentPlaceHolder ID="head" runat="server">
          <title>Please change my title</title>
          <meta name="description" content="Please provide a description" />
          <meta name="keywords" content="keyword1,keyword2" />
     </asp:ContentPlaceHolder>
</head>
<body>
     <div>

          <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">

          </asp:ContentPlaceHolder>
     </div>
</body>
</html>
        
Notice that the <asp:ContentPlaceHolder> tag in Listing 4 includes default content: a default title and default meta tags. If you don't override this <asp:ContentPlaceHolder> tag in an individual view content page, then the default content will be displayed.
The content view page in Listing 5 overrides the <asp:ContentPlaceHolder> tag in order to display a custom title and custom meta tags.
Listing 5 – Views\Home\Index2.aspx
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site2.Master" AutoEventWireup="true" CodeBehind="Index2.aspx.cs" Inherits="MvcApplication1.Views.Home.Index2" %>

<asp:Content ID="Content1" ContentPlaceHolderID="head" runat="server">
     <title>The Index2 Page</title>
     <meta name="description" content="Description of Index2 page" />
     <meta name="keywords" content="asp.net,mvc,cool,groovy" />    
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">

     Just some content in the body of the page.

</asp:Content>

        

Summary

This tutorial provided you with a basic introduction to view master pages and view content pages. You learned how to create new view master pages and create view content pages based on them. We also examined how you can modify the content of a view master page from a particular view content page.

Passing Data to View Master Pages (C#)
The goal of this tutorial is to explain how you can pass data from a controller to a view master page. We examine two strategies for passing data to a view master page. First, we discuss an easy solution that results in an application that is difficult to maintain. Next, we examine a much better solution that requires a little more initial work but results in a much more maintainable application.

Passing Data to View Master Pages

The goal of this tutorial is to explain how you can pass data from a controller to a view master page. We examine two strategies for passing data to a view master page. First, we discuss an easy solution that results in an application that is difficult to maintain. Next, we examine a much better solution that requires a little more initial work but results in a much more maintainable application.

The Problem

Imagine that you are building a movie database application and you want to display the list of movie categories on every page in your application (see Figure 1). Imagine, furthermore, that the list of movie categories is stored in a database table. In that case, it would make sense to retrieve the categories from the database and render the list of movie categories within a view master page.
Displaying movie categories in a view master page
Figure 01: Displaying movie categories in a view master page (Click to view full-size image)
Here's the problem. How do you retrieve the list of movie categories in the master page? It is tempting to call methods of your model classes in the master page directly. In other words, it is tempting to include the code for retrieving the data from the database right in your master page. However, bypassing your MVC controllers to access the database would violate the clean separation of concerns that is one of the primary benefits of building an MVC application.
In an MVC application, you want all interaction between your MVC views and your MVC model to be handled by your MVC controllers. This separation of concerns results in a more maintainable, adaptable, and testable application.
In an MVC application, all data passed to a view – including a view master page – should be passed to a view by a controller action. Furthermore, the data should be passed by taking advantage of view data. In the remainder of this tutorial, I examine two methods of passing view data to a view master page.

The Simple Solution

Let's start with the simplest solution to passing view data from a controller to a view master page. The simplest solution is to pass the view data for the master page in each and every controller action.
Consider the controller in Listing 1. It exposes two actions named Index() and Details(). The Index() action method returns every movie in the Movies database table. The Details() action method returns every movie in a particular movie category.
Listing 1 – Controllers\HomeController.cs
using System.Linq;
using System.Web.Mvc;
using MvcApplication1.Models;

namespace MvcApplication1.Controllers
{
     [HandleError]
     public class HomeController : Controller
     {
          private MovieDataContext _dataContext = new MovieDataContext();

          /// <summary>

          /// Show list of all movies
          /// </summary>
          public ActionResult Index()
          {
               ViewData["categories"] = from c in _dataContext.MovieCategories 
      &origin=https%3A%2F%2Fwww.blogger.com&inparent=true&hl=en&source=wmtn%3Ablogger&jsh=m%3B%2F_%2Fscs%2Fabc-static%2F_%2Fjs%2Fk%3Dgapi.gapi.en.5GL3tg_C6Nc.O%2Fm%3D__features__%2Frt%3Dj%2Fd%3D1%2Frs%3DAItRSTPfsfz-ifAZeiHMk7mKfiGQJuhVFw#rpctoken=239815738&_methods=onstatechange%2C_ready%2C_close%2C_open%2C_resizeMe%2C_renderstart&id=I1_1389037338941&parent=https%3A%2F%2Fwww.blogger.com&pfname=                   select c;
               ViewData["movies"] = from m in _dataContext.Movies 
                         select m;
               return View();
          }

          /// <summary>
          /// Show list of movies in a category
          /// </summary>

          public ActionResult Details(int id)
          {
               ViewData["categories"] = from c in _dataContext.MovieCategories 
                         select c;
               ViewData["movies"] = from m in _dataContext.Movies 
                         where m.CategoryId == id
                         select m;
               return View();
          }
     }
}
        
Notice that both the Index() and the Details() actions add two items to view data. The Index() action adds two keys: categories and movies. The categories key represents the list of movie categories displayed by the view master page. The movies key represents the list of movies displayed by the Index view page.
The Details() action also adds two keys named categories and movies. The categories key, once again, represents the list of movie categories displayed by the view master page. The movies key represents the list of movies in a particular category displayed by the Details view page (see Figure 2).
The Details view
Figure 02: The Details view (Click to view full-size image)
The Index view is contained in Listing 2. It simply iterates through the list of movies represented by the movies item in view data.
Listing 2 – Views\Home\Index.aspx
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Views.Home.Index" %>

<%@ Import Namespace="MvcApplication1.Models" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">

<ul>

<% foreach (var m in (IEnumerable<Movie>)ViewData["movies"])
     { %>

     <li><%= m.Title %></li>

<% } %>
</ul>

</asp:Content>
        
The view master page is contained in Listing 3. The view master page iterates and renders all of the movie categories represented by the categories item from view data.
Listing 3 – Views\Shared\Site.master
<%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Site.Master.cs" Inherits="MvcApplication1.Views.Shared.Site" %>
<%@ Import Namespace="MvcApplication1.Models" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
     <title></title>
     <asp:ContentPlaceHolder ID="head" runat="server">

     </asp:ContentPlaceHolder>
</head>
<body>
     <div>
          <h1>My Movie Website</h1>

          <% foreach (var c in (IEnumerable<MovieCategory>)ViewData["categories"])
                           {%>

               <%= Html.ActionLink(c.Name, "Details", new {id=c.Id} ) %> 

          <% } %>


          <asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">

          </asp:ContentPlaceHolder>
     </div>
</body>
</html>

        
All data is passed to the view and the view master page through view data. That is the correct way to pass data to the master page.
So, what's wrong with this solution? The problem is that this solution violates the DRY (Don't Repeat Yourself) principle. Each and every controller action must add the very same list of movie categories to view data. Having duplicate code in your application makes your application much more difficult to maintain, adapt, and modify.

The Good Solution

In this section, we examine an alternative, and better, solution to passing data from a controller action to a view master page. Instead of adding the movie categories for the master page in each and every controller action, we add the movie categories to the view data only once. All view data used by the view master page is added in an Application controller.
The ApplicationController class is contained in Listing 4.
Listing 4 – Controllers\ApplicationController.cs
using System.Linq;
using System.Web.Mvc;
using MvcApplication1.Models;

namespace MvcApplication1.Controllers
{
     public abstract class ApplicationController : Controller
     {
          private MovieDataContext _dataContext = new MovieDataContext();

          public MovieDataContext DataContext
          {
               get { return _dataContext; }
          }

          public ApplicationController()
          {
               ViewData["categories"] = from c in DataContext.MovieCategories 
                         select c;
          }

     }
}
        
There are three things that you should notice about the Application controller in Listing 4. First, notice that the class inherits from the base System.Web.Mvc.Controller class. The Application controller is a controller class.
Second, notice that the Application controller class is an abstract class. An abstract class is a class that must be implemented by a concrete class. Because the Application controller is an abstract class, you cannot not invoke any methods defined in the class directly. If you attempt to invoke the Application class directly then you'll get a Resource Cannot Be Found error message.
Third, notice that the Application controller contains a constructor that adds the list of movie categories to view data. Every controller class that inherits from the Application controller calls the Application controller's constructor automatically. Whenever you call any action on any controller that inherits from the Application controller, the movie categories is included in the view data automatically.
The Movies controller in Listing 5 inherits from the Application controller.
Listing 5 – Controllers\MoviesController.cs
using System.Linq;
using System.Web.Mvc;

namespace MvcApplication1.Controllers
{
     public class MoviesController : ApplicationController
     {
          /// <summary>

          /// Show list of all movies
          /// </summary>
          public ActionResult Index()
          {
               ViewData["movies"] = from m in DataContext.Movies 
                         select m;
               return View();
          }

          /// <summary>
          /// Show list of movies in a category
          /// </summary>

          public ActionResult Details(int id)
          {
               ViewData["movies"] = from m in DataContext.Movies
                         where m.CategoryId == id
                         select m;
               return View();
          }

     }
}
        
The Movies controller, just like the Home controller discussed in the previous section, exposes two action methods named Index() and Details(). Notice that the list of movie categories displayed by the view master page is not added to view data in either the Index() or Details() method. Because the Movies controller inherits from the Application controller, the list of movie categories is added to view data automatically.
Notice that this solution to adding view data for a view master page does not violate the DRY (Don't Repeat Yourself) principle. The code for adding the list of movie categories to view data is contained in only one location: the constructor for the Application controller.

Summary

In this tutorial, we discussed two approaches to passing view data from a controller to a view master page. First, we examined a simple, but difficult to maintain approach. In the first section, we discussed how you can add view data for a view master page in each every controller action in your application. We concluded that this was a bad approach because it violates the DRY (Don't Repeat Yourself) principle.
Next, we examined a much better strategy for adding data required by a view master page to view data. Instead of adding the view data in each and every controller action, we added the view data only once within an Application controller. That way, you can avoid duplicate code when passing data to a view master page in an ASP.NET MVC application.
ASP.NET MVC Views Overview (VB)
What is an ASP.NET MVC View and how does it differ from a HTML page? In this tutorial, Stephen Walther introduces you to Views and demonstrates how you can take advantage of View Data and HTML Helpers within a View.
The purpose of this tutorial is to provide you with a brief introduction to ASP.NET MVC views, view data, and HTML Helpers. By the end of this tutorial, you should understand how to create new views, pass data from a controller to a view, and use HTML Helpers to generate content in a view.

Understanding Views

Unlike ASP.NET or Active Server Pages, ASP.NET MVC does not include anything that directly corresponds to a page. In an ASP.NET MVC application, there is not a page on disk that corresponds to the path in the URL that you type into the address bar of your browser. The closest thing to a page in an ASP.NET MVC application is something called a view.
In an ASP.NET MVC application, incoming browser requests are mapped to controller actions. A controller action might return a view. However, a controller action might perform some other type of action such as redirecting you to another controller action.
Listing 1 contains a simple controller named the HomeController. The HomeController exposes two controller actions named Index() and Details().
Listing 1 - HomeController.vb
<HandleError()> _
Public Class HomeController
    Inherits System.Web.Mvc.Controller

    Function Index()
        Return View()
    End Function

    Function Details()
        Return RedirectToAction("Index")
    End Function
End Class
You can invoke the first action, the Index() action, by typing the following URL into your browser address bar:
/Home/Index
You can invoke the second action, the Details() action, by typing this address into your browser:
/Home/Details
The Index() action returns a view. Most actions that you create will return views. However, an action can return other types of action results. For example, the Details() action returns a RedirectToActionResult that redirects incoming request to the Index() action.
The Index() action contains the following single line of code:
View()
This line of code returns a view that must be located at the following path on your web server:
\Views\Home\Index.aspx
The path to the view is inferred from the name of the controller and the name of the controller action.
If you prefer, you can be explicit about the view. The following line of code returns a view named Fred :
View( Fred )
When this line of code is executed, a view is returned from the following path:
\Views\Home\Fred.aspx

If you plan to create unit tests for your ASP.NET MVC application then it is a good idea to be explicit about view names. That way, you can create a unit test to verify that the expected view was returned by a controller action.

Adding Content to a View

A view is a standard (X)HTML document that can contain scripts. You use scripts to add dynamic content to a view.
For example, the view in Listing 2 displays the current date and time.
Listing 2 - \Views\Home\Index.aspx
<%@ Page Language="VB" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Index</title>
</head>
<body>
    <div>
     
    The current date and time is
    <% Response.Write(DateTime.Now)%>
    
    </div>
</body>
</html>
Notice that the body of the HTML page in Listing 2 contains the following script:
<% Response.Write(DateTime.Now)%>
You use the script delimiters <% and %> to mark the beginning and end of a script. This script is written in Visual basic. It displays the current date and time by calling the Response.Write() method to render content to the browser. The script delimiters <% and %> can be used to execute one or more statements.
Since you call Response.Write() so often, Microsoft provides you with a shortcut for calling the Response.Write() method. The view in Listing 3 uses the delimiters <%= and %> as a shortcut for calling Response.Write().
Listing 3 - Views\Home\Index2.aspx
<%@ Page Language="VB" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Index</title>
</head>
<body>
    <div>
     
    The current date and time is
    <%= DateTime.Now %>
    
    </div>
</body>
</html>
You can use any .NET language to generate dynamic content in a view. Normally, you�ll use either Visual Basic .NET or C# to write your controllers and views.

Using HTML Helpers to Generate View Content

To make it easier to add content to a view, you can take advantage of something called an HTML Helper. An HTML Helper, typically, is a method that generates a string. You can use HTML Helpers to generate standard HTML elements such as textboxes, links, dropdown lists, and list boxes.
For example, the view in Listing 4 takes advantage of three HTML Helpers -- the BeginForm(), the TextBox() and Password() helpers -- to generate a Login form (see Figure 1).
Listing 4 -- \Views\Home\Login.aspx
<%@ Page Language="VB" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Login Form</title>
</head>
<body>
    <div>
    
        
    <%  Using Html.BeginForm()%>
    
    
        <label for="UserName">User Name:</label>
        <br />
        <%= Html.TextBox("UserName") %>
        
        <br /><br />
            
        <label for="Password">Password:</label>
        <br />
        <%= Html.Password("Password") %>
        
        <br /><br />

        <input type="submit" value="Log in" />        
    
    <% End Using%>

    
    </div>
</body>
</html>
The New Project dialog box
Figure 01: A standard Login form (Click to view full-size image)
All of the HTML Helpers methods are called on the Html property of the view. For example, you render a TextBox by calling the Html.TextBox() method.
Notice that you use the script delimiters <%= and %> when calling both the Html.TextBox() and Html.Password() helpers. These helpers simply return a string. You need to call Response.Write() in order to render the string to the browser.
Using HTML Helper methods is optional. They make your life easier by reducing the amount of HTML and script that you need to write. The view in Listing 5 renders the exact same form as the view in Listing 4 without using HTML Helpers.
Listing 5 -- \Views\Home\Login.aspx
<%@ Page Language="VB" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Login Form</title>
</head>
<body>
    <div>
        
    <form method="post" action="/Home/Login">
    
    <label for="userName">User Name:</label>
    <br />
    <input name="userName" />
    
    <br /><br />
    
    <label for="password">Password:</label>
    <br />
    <input name="password" type="password" />
    
    <br /><br />
    <input type="submit" value="Log In" />
    
    </form>
    
    </div>
</body>
</html>
You also have the option of creating your own HTML Helpers. For example, you can create a GridView() helper method that displays a set of database records in an HTML table automatically. We explore this topic in the tutorialCreating Custom HTML Helpers.

Using View Data to Pass Data to a View

You use view data to pass data from a controller to a view. Think of view data like a package that you send through the mail. All data passed from a controller to a view must be sent using this package. For example, the controller in Listing 6 adds a message to view data.
Listing 6 - ProductController.vb
Public Class ProductController
    Inherits System.Web.Mvc.Controller

    Function Index()
        ViewData("message") = "Hello World!"
        Return View()
    End Function

End Class
The controller ViewData property represents a collection of name and value pairs. In Listing 6, the Index() method adds an item to the view data collection named message with the value Hello World! . When the view is returned by the Index() method, the view data is passed to the view automatically.
The view in Listing 7 retrieves the message from the view data and renders the message to the browser.
Listing 7 -- \Views\Product\Index.aspx
<%@ Page Language="VB" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Product Index</title>
</head>
<body>
    <div>
    
    
    <%=Html.Encode(ViewData("message"))%>
    
    </div>
</body>
</html>
Notice that the view takes advantage of the Html.Encode() HTML Helper method when rendering the message. The Html.Encode() HTML Helper encodes special characters such as < and > into characters that are safe to display in a web page. Whenever you render content that a user submits to a website, you should encode the content to prevent JavaScript injection attacks.
(Because we created the message ourselves in the ProductController, we don�t really need to encode the message. However, it is a good habit to always call the Html.Encode() method when displaying content retrieved from view data within a view.)
In Listing 7, we took advantage of view data to pass a simple string message from a controller to a view. You also can use view data to pass other types of data, such as a collection of database records, from a controller to a view. For example, if you want to display the contents of the Products database table in a view, then you would pass the collection of database records in view data.
You also have the option of passing strongly typed view data from a controller to a view. We explore this topic in the tutorial Understanding Strongly Typed View Data and Views.

Summary

This tutorial provided a brief introduction to ASP.NET MVC views, view data, and HTML Helpers. In the first section, you learned how to add new views to your project. You learned that you must add a view to the right folder in order to call it from a particular controller. Next, we discussed the topic of HTML Helpers. You learned how HTML Helpers enable you to easily generate standard HTML content. Finally, you learned how to take advantage of view data to pass data from a controller to a view.