ASP.NET MVC3 includes a new class HttpNotFoundResult in  System.Web.Mvc namespace.

HttpNotFoundResult: Instance of HttpNotFoundResult class indicates to client(browser) that the requested resource was not found. It returns a 404 HTTP status code to the client. Generally we return 404 status code if a requested webpage is not available. In case of MVC applications we return 404 status code is in terms of resources, for example we are searching for particular user profile in the portal, if the user profile is not found, we can return 404.

How to return 404 status code from a MVC application?
First way is to instantiate HttpNotFoundResult class and return the object.

public ActionResult Index()
{
            var result = new HttpNotFoundResult();
            return result;
}

Next alternative is to makes use of HttpNotFound() helper method of the Controller class which returns the HttpNotFoundResult instance.

public ActionResult Index()
{
             return HttpNotFound();
}

we can return 404 along with custom status code description,using the overloded version of HttpNotFound(string statusDescription).

public ActionResult Index()
{
             return HttpNotFound("can not find requested resource");
}

Every website has to display data and every website has a Grid control. In ASP.NET MVC 3 there’s the WebGrid, which is part of the Microsoft Web Helpers library. This can be downloaded through NuGet (formerly NuPack). NuGet is a free open source package manager that makes it easy for you to find, install, and use .NET libraries in your projects. One piece of functionality that is critical is reacting when the user selects an item in the WebGrid. This article will focus on finding out which row was selected, but also how to find out more about the data that is selected.

Before moving on, you need to download ASP.NET MVC 3. Click here to download and install them using the Microsoft Web Platform Installer.

Open studio 2010 and create a new ASP.NET MVC 3 Web Application (Razor) project. To focus on the answer, I’ve got a simple model as seen below.



Using the WebGrid, it’s easy to display this data to the user.



The first column is the key to making this work. @item.GetSelectLink outputs a HTML anchor tag with the row selected. This is passed as a QueryString, and the name of the QueryString is set by the selectionFieldName property set on the grid.



To find out what row is selected is just as easy. The WebGrid has a property called SelectedRow. This sets a reference to a GridViewRow object that represents the selected row in the control. When you combine this with the HasSelection property, you can get the selected row like this.



I’ve created a partial view called _Person.cshtml. The file begins with an underscore (_) because I don’t want this file called directly from the web. The second parameter is the data being passed into the partial view. The data in this instance is the selected row.



The partial view has then got access to all the data in the selected row. Nice and easy. Thanks Microsoft!

ASP.NET MVC 3 introduces two new interfaces to allow simple integration of IoC containers into the MVC pipeline, allowing many different types to be resolved using your IoC container of choice. These interfaces are IDependencyResolver and IControllerActivator but before you go ahead and implement both, let's take a look at whether they are both actually needed.

First some background

If you wanted to inject dependencies into your controllers in ASP.NET MVC 2, you were required to either implement IControllerFactory or subclass DefaultControllerFactory. Typically, you would pass your IoC container into the constructor of your custom controller factory and use it to resolve the controller in the CreateController method. You may also have added custom code in ReleaseController to clean up dependencies

This worked reasonably well, but in ASP.NET MVC 3 things have changed so we can use DI for a whole host of other objects such as filters and view engines

The new interface that we should implement is IDependencyResolver:

The important thing about your implementation of this interface is that it should return null if it cannot resolve a particular object. Below is a simple implementation using Unity:


When an MVC application starts for the first time, the dependency resolver is called with the following types in the following order:
- IControllerFactory
- IControllerActivator
- HomeController
….

If you do not implement IControllerFactory or IControllerActivator, then the MVC framework will try to get the controller from the DependencyResolver itself. As a side note, there is no need to worry about performance (regarding so many calls to the resolver) because MVC will only try to resolve theIControllerFactory and IControllerActivator once on startup and if no implementations are registered then it will subsequently always query the DependencyResolver first

The MVC framework goes on to try to resolve many other types which you probably have not implemented or registered with your IoC container, but as long as your dependency resolver returns null if the type is not registered, MVC will default back to the built-in implementations

If you did not implement your resolver to return null if a type is not registered then you will probably end up seeing an error similar to:

The current type, System.Web.Mvc.IControllerFactory, is an interface and cannot be constructed

The other important thing to note is that both methods on this interface take in the actual service type. This typically means that when you register your controllers with your IoC container, you should only specify the concrete type, not the IController, interface

i.e. using Unity as an example:


rather than:


Failing to register your controllers conrrectly and you will see

No parameterless constructor defined for this object

So at this stage, we have an implementation of IDependencyResolver and nothing else and yet our controller are all resolving correctly. It makes you wonder about whether IControllerActivator is really needed...

About IControllerActivator

IControllerActivator was introduced with ASP.NET MVC 3 to split the functionality of the MVC 2 controller factory into two distinct classes. As far as we can tell, this was done to adhere to the Single Responsibility Principle (SRP). So now in MVC 3, the DefaultControllerFactory outsources the responsibility of actually instantiating the controller to the controller activator. The single method interface is shown below:


If you implement this interface and register your activator with your IoC container, the MVC framework will pick it up and use it when trying to instantiate controllers, but you have to wonder why you would do this instead of just letting your dependency resolver do it directly. Brad Wilson to the rescue:

"If your container can build arbitrary types, you don't need to write activators. The activator services are there for containers that can't be arbitrary types. MEF can't, but you can add [Export] attributes to your controllers to allow MEF to build them..."

This means that if you are working with any competent IoC container* (Castle Windor, Unity, Ninject, StructureMap, Autofac et al), IControllerActivator is not needed and offers no benefit over allowing your DependencyResolver to instantiate your controllers.

* (With the exception of MEF which isn't an IoC container any way)

So we now know that we are probably not required to implement this interface, but are there any benefits to doing so? Something that we have seen mentioned (we cannot remember where) is that implementing IControllerActivator allows you you can provide a more meaningful error message if resolution fails. It is true that the message you would get otherwise (No parameterless constructor defined for this object) is not 100% clear, but we are not sure that this justifies another class just for this purpose. Surely, once you have seen this message, the next time you encounter, it you will immediately know what the problem is. Even if you do implement IControllerActivator, you will not have access to the (normally) detailed message that you IoC container provides when resolution fails, so you can do little more than say resolution failed - i don't know why.

Conclusion

So, should you implement IControllerActivator? Probably not. If you are using pretty much any well known IoC container, just implement IDependencyResolver and it will do everything for you. There is also no need for a custom implementation of IControllerFactory. If you are worried about the lack of release method on the dependency resolver, don't be. The worst case scenario requires a small change to the way that you are using your IoC container. Next time we will talk about how to make sure your dependency resolver plays nicely with IDisposable

Today, we found a good answer on syntax highlighting for Razor. In the Visual Studio Gallery located at http://visualstudiogallery.msdn.microsoft.com/en-us/8dc77b9c-7c83-4392-9c46-fd15f3927a2e, a new Visual Studio extension has been recently added for a “Razor Syntax Highlighter”.



To leverage this new extension, we had to remove the editor mapping for .cshtml files in the Visual Studio Text Editor/File Extensions window and install the highlighter extension. As you see in the figure below, it worked great. This new extension uses the Razor Parser libraries to appropriately highlight the Razor code.

Figure 1 - Syntax Highlighting Visual studio 2010 Add-on

Unfortunately, this feature is offered as a Visual Studio Extension and hence is only available for paid-for Visual Studio 2010 editions.

Looking at the Razor Syntax, one can summarize it as a means to short-hand the <%= %> used in ASPX pages to designate code sections. For Razor, only a simple @ sign is used in-place of that bulky aforementioned code markup . Additionally, the Razor parser introduces helpful intelligence that makes the syntax even more user-friendly. For instance the following is a code block you would see in an ASPX page:

<%=if(true){%>
       <input type="hidden" value="istrue"/>
<%}%>  

The corresponding Razor block for this snippet would be:

@if(true){
       <input type="hidden" value="istrue"/>
}

The Razor syntax has simply “inferred” that the code will have a closing curly bracket without us having to apply any special markup tags to it. This further reduces the markup needed to accomplish the same task.

An important difference between Razor and ASPX View Engines is the absence of master pages for the earlier. Razor simply provides a _ViewStart.cshtml to bootstrap our application layout.

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

Latest Razor Beta does however support Partial rendering (RenderPartial) to explicitly render a Partial View as well as calling @RenderBody() which loads the actual view content to be served.

Next, we will be talking about creating an MVC project with dual support for ASPX/Razor View Engines as well as further explore the Razor syntax.

For past couple of days we were checking out features of the new ASP.NET MVC Preview 3.There are couple of interesting new additions like integration with the new Razor viewengine,improvements in Model Validation,AJAX support and Dependency Injection. In this post we will discuss on, how ASP.NET MVC 3 has streamlined the ability to register/retrieve objects/services in a loosely coupled manner by incorporating support for the Common Service Locator framework.

What is Common Service Locator?Today we have many Inversion of Control/Dependency Injection Containers like NInject,StructureMap,Unity,.. etc in the .NET world.Most of these vary quite widely in terms of configuration and initialization/registration of the instances.But they provide more or less similar interface while resolving the dependencies and returning object instances.Common Service Locator framework extracts these commonalities out and provides an abstraction on top of these IoC/DI containers.This is now part of the Enterprise Library 5.0 and used in the Enterprise Library code to create/retrieve objects.Common Service Locator provides an interface IServiceLocator

It is quite evident from the method signatures that these are only related to retrieval of right object instances with proper resolution of the dependencies based upon different parameters.

Another important class related to the Common Service Locator is the ActivationException which needs to be thrown whenever there is exception in instantiating the objects /resolving the dependencies.

We were planning to use StructureMap as the DI Container and a StructureMap Adapter for Service Locator was available in Codeplex but that seemed far from complete.

So we went ahead to write few lines of code and develop a service locator which will use StructureMap as the DI container as shown below:

This class accepts an instance of the StructureMap.Container in the constructor and uses it to resolve dependencies and instantiate objects.In the implementation of the IServiceLocator methods we have to just map them suitably to StructureMap.Container.GetAllInstances and StructureMap.Container.GetInstance methods (and their overloads).The code which depends on IServiceLocator will perform exception handling based on ActivationException class whereas StructureMap raises StructureMap.StructureMapException in most of the cases.So we need to catch StructureMapException in this class and throw a ActivationException.The complete code is given below:

So we have our Service Locator class ready.In next part of the post we will see how we can plug this into the ASP.NET MVC 3.0 Framework

Introduction

One of the new features in ASP.NET MVC 3 is the ability to register a service locator that will be used by the framework. Prior versions of the MVC framework have offered opportunities for introducing concepts like service location and dependency injection (DI); in MVC 3, we have formalized the process and opened up several new opportunities for developers

This first post in the series will discuss the general strategy for service location in MVC 3. Later posts will discuss specific ways to perform service location and DI with existing and new features



Disclaimer

This blog post talks about ASP.NET MVC 3 Preview 1, which is a pre-release version. Specific technical details may change before the final release of MVC 3. This release is designed to elicit feedback on features with enough time to make meaningful changes before MVC 3 ships


General Strategy

The most important part of the strategy with service location is that it's going to be optional. This means that if you are not interested in working with a service locator, you won't be forced to. We will always offer a way to perform customization functions without requiring you to employ a service locator. We will also work to preserve backward compatibility as much as possible when introducing new service location capability into existing features of MVC

When using the registered service locator, MVC will generally employ one of three strategies, depending on the kind of work it's trying to do

1. Locating a singly registered service

There are several services which MVC uses today which have the ability to register a single instance of such a service. One example is the controller factory, which implements IControllerFactory. There is a single controller factory that's used for the entire application

When MVC attempts to use a singly registered service, it will first ask the service locator whether it has an instance of that service available. If it does, then MVC will use that; if it does not, then it will fall back to the singleton registration that's available for non-service locator users

The upside of this means that service locator users won't be required to fill their locator/container with all the existing default services used by MVC, because it will automatically fall back to these defaults when nothing exists in the locator. The potential downside of this means that it is theoretically possible to register a custom service in both places, but only the one in the locator will be used

2. Locating a multiply registered service

There are several services which MVC uses today which have the ability to register multiple instances of such a service. One example of this is the view engine, which implements IViewEngine. Typically, MVC offers a registration point which acts like a list of such services, and also offers an API which acts as a facade and figures out the appropriate way to do the work. In the case of view engines, this facade (ViewEngines.Engines) takes the form of "go to each view engine on the list and ask it for a view until one of them can provide it". There are also multiply registered services where the facade uses all the services (ModelValidatorProviders.Providers) and aggregates all the responses together

When MVC attempts to use a multiply registered service, it will continue to ask the collection facade to do the work. The collection facade will use both the statically registered instances of the service as well as any of the instances registered with the service locator, and combines them together in the way that is most appropriate for the facade. Where service order is important (as with view engines, for example), this usually means that the service locator instances will come before the statically registered instances

Like the single registration strategy, the upside of this means that service locator users won't be required to fill their locator/container with the existing default service instances. The potential downside of this is that most containers don't offer a native ordering function for multi-registration of services, so where ordering is important, it may be necessary to use the non-service locator APIs. In practice, however, it probably won't be much of an issue, as most applications don't generally need to rely on ordering (for example, they will only primarily use a single view engine), especially since service locator services generally go before the existing pre-registered services

3. Creating arbitrary objects

The final way that MVC may use a service locator is in the creation of arbitrary objects. (This is where we stray from the strictly service location functionality and use it more like a dependency injection container.) Where we've found it appropriate that an object we create may be in need of dependency injection of services, we will attempt to create that object through the service locator. One example is controller objects, which may want to take service dependencies to do their work

When MVC attempts to create an arbitrary object in this way, it will ask the service locator to create the object on its behalf. If the service locator cannot fulfill this object creation, it will generally fall back to the existing behavior in prior versions of MVC 2; usually, this means calling Activator.CreateInstance


IMvcServiceLocator and MvcServiceLocator

To enable service location in MVC, we've introduced a new interface (IMvcServiceLocator) and a new static singleton registration class (MvcServiceLocator). For Preview 1, we have also replicated the existing Common Service Locator interface (IServiceLocator) and exception class (ActivationException) in the System.Web.Mvc namespace

public interface IServiceLocator : IServiceProvider { 
    IEnumerable<TService> GetAllInstances<TService>(); 
    IEnumerable<object> GetAllInstances(Type serviceType); 
    TService GetInstance<TService>(); 
    TService GetInstance<TService>(string key); 
    object GetInstance(Type serviceType); 
    object GetInstance(Type serviceType, string key);
}   
public interface IMvcServiceLocator : IServiceLocator { 
    void Release(object instance);
}   
public static class MvcServiceLocator { 
    public static IMvcServiceLocator Current { get; } 
    public static IMvcServiceLocator Default { get; } 
    public static void SetCurrent(IServiceLocator locator);

The registration point is MvcServiceLocator.SetCurrent(), and only requires the service locator to support IServiceLocator. However, you'll notice that MvcServiceLocator.Current always returns an implementation of IMvcServiceLocator. We will automatically create the implementation of IMvcServiceLocator.Release() if one does not exist, which will call Dispose on the object if it implements Idisposable

It's also worth noting that there will always be a service locator available, even if you've never registered one. Our default service locator is not a full fledged service locator, as it only calls Activator.CreateInstance and offers no registration system. It is not meant to be a replacement for a real service locator or dependency injection container


No Configuration

MVC's usage of service location is limited to retrieving services. MVC has no need to configure the existing service locator. As such, we have made no effort to hide the configuration/registration process inherent to existing service locators or DI containers

We feel that most people will choose the container they want to use based on its registration and configuration APIs, so attempting to hide them would be counter productive


Complex Dependency Injection Needs

Razor is the new view engine that is available for ASP.NET MVC 3 Beta. Razor has directives that are the same as the WebForms view engine, so you can define namespaces at the top of the Razor file so you don’t have to use the fully qualified name when referencing objects. One of the keywords available is the new @model keyword. This keyword defines the model that is being used in the view. By default the default value is dynamic, which means you’re using a dynamic model for your view. However you can change this so you can use a strongly typed view. This article will demonstrate how to use both



Before moving on, you need to download ASP.NET MVC 3 Beta and NuPack. Click here to download and install them using the Microsoft Web Platform Installer.

Open studio 2010 and create a new ASP.NET MVC 3 Web Application (Razor) project. The new MVC 3 Beta dialog can be seen below



Choose Razor as the view engine and click OK

We’re going to add a model called FavouriteGivenName which will store the most popular given names in Australia for 2009. We’re going to add a new controller named MostPopular and add the following code:

private readonly List<FavouriteGivenName> _mostPopular = null;
        public MostPopularController()
        {
            _mostPopular = new List<FavouriteGivenName>()
                {
                    new FavouriteGivenName() {Name = "Jack"},
                    new FavouriteGivenName() {Name = "Riley"},
                    new FavouriteGivenName() {Name = "William"},
                    new FavouriteGivenName() {Name = "Oliver"},
                    new FavouriteGivenName() {Name = "Lachlan"},
                    new FavouriteGivenName() {Name = "Thomas"},
                    new FavouriteGivenName() {Name = "Joshua"},
                    new FavouriteGivenName() {Name = "James"},
                    new FavouriteGivenName() {Name = "Liam"},
                    new FavouriteGivenName() {Name = "Max"}
                };
        }

        public ActionResult DynamicView()
        {
            return View(_mostPopular);
        }

We’ll add a new view, but we won’t select Create a strongly-typed view



Upon completion the view’s HTML is the following

@model dynamic
@{
    View.Title = "DynamicView";
    Layout = "~/Views/Shared/_LayoutPage.cshtml";
}

<h2>Dynamic View</h2>

You’ll notice in the code above, the first line contains the @model keyword and it’s dynamic.

@model dynamic

This means you won’t have access to a strongly-typed object when you code this view. You can use the following code to render the popular names to the view.

@model dynamic
@{

    View.Title = "DynamicView";

    Layout = "~/Views/Shared/_LayoutPage.cshtml";

}

<h2>Dynamic View</h2>

<p>
      @foreach(var givenName in Model) {

            @givenName.Name <br />

      }

</p>

On the other hand you wanted a strong-typed view and not rely on dynamic views, it’s easy. Add another action and create a new view, but this time select Create a strongly-typed view



By default you’ll now have a strongly typed view as shown in the code snippet below

@model IEnumerable<MvcApplication5.Models.FavouriteGivenName>

@{

    View.Title = "StronglyTypedView";

    Layout = "~/Views/Shared/_LayoutPage.cshtml";

}

<h2>Strongly Typed View</h2>

Now the model is a list of strongly-typed FavouriteName objects. Intellisense doesn’t work in the beta version, so we are unable to show you the benefits of using a strongly-typed view. You can use the following code to render the favourite given names:

@model IEnumerable<MvcApplication5.Models.FavouriteGivenName>
@{
    View.Title = "StronglyTypedView";
    Layout = "~/Views/Shared/_LayoutPage.cshtml";
}

<h2>Strongly Typed View</h2>
<p>
      @foreach(var givenName in Model) {
            @givenName.Name <br />
      }
</p>

The @model keyword is easy to miss when you’re using the beta version of ASP.NET MVC 3 Beta, but it’s something you’ll learn once and never forget it’s there.

Brief Description

ASP.NET MVC 3 Preview 1 provides a new Model-View-Controller (MVC) framework on top of the existing ASP.NET 4 runtime


Overview

ASP.NET MVC 3 is a framework for developing highly testable and maintainable Web applications by leveraging the Model-View-Controller (MVC) pattern. The framework encourages developers to maintain a clear separation of concerns among the responsibilities of the application – the UI logic using the view, user-input handling using the controller, and the domain logic using the model. ASP.NET MVC applications are easily testable using techniques such as test-driven development (TDD).

The installation package includes templates and tools for Visual Studio 2010 to increase productivity when writing ASP.NET MVC applications. For example, the Add View dialog box takes advantage of customizable code generation (T4) templates to generate a view based on a model object. The default project template allows the developer to automatically hook up a unit-test project that is associated with the ASP.NET MVC application.
Because the ASP.NET MVC framework is built on ASP.NET 4, developers can take advantage of existing ASP.NET features like authentication and authorization, profile settings, localization, and so on


System Requirements

Supported Operating Systems:Windows 7;Windows Server 2003;Windows Server 2008;Windows Vista

.NET 4, ASP.NET 4, Visual Studio 2010 or Visual Web Developer 2010 are required to use certain parts of this feature


Instructions

For more information about installing the release, see the ASP.NET MVC 3 Preview 1 Release Notes


Top Reasons to trust your ASP.NET MVC 3 website to ASPHostCentral.com

What we think makes ASPHostCentral.com so compelling is how deeply integrated all the pieces are. We integrate and centralize everything--from the systems to the control panel software to the process of buying a domain name. For us, that means we can innovate literally everywhere. We've put the guys who develop the software and the admins who watch over the server right next to the 24-hour Fanatical Support team, so we all learn from each other:

- 24/7-based Support - We never fall asleep and we run a service that is operating 24/7 a year. Even everyone is on holiday during Easter or Christmas/New Year, we are always behind our desk serving our customers
- Excellent Uptime Rate - Our key strength in delivering the service to you is to maintain our server uptime rate. We never ever happy to see your site goes down and we truly understand that it will hurt your onlines business. If your service is down, it will certainly become our pain and we will certainly look for the right pill to kill the pain ASAP
- High Performance and Reliable Server - We never ever overload our server with tons of clients. We always load balance our server to make sure we can deliver an excellent service, coupling with the high performance and reliable server
- Experts in ASP.NET MVC 3 Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostCentral
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!

Happy hosting!