MVC4

@html
With MVC, HTML helpers are much like traditional ASP.NET Web Form controls.
Just like web form controls in ASP.NET, HTML helpers are used to modify HTML. But HTML helpers are more lightweight. Unlike Web Form controls, an HTML helper does not have an event model and a view state.In most cases, an HTML helper is just a method that returns a string.
With MVC, you can create your own helpers, or use the built in HTML helpers.

@Html.ActionLink
The easiest way to render an HTML link in is to use the @html.ActionLink() helper.With MVC, the @html.ActionLink() does not link to a view. It creates a link to a controller action.

Syntax : @Html.ActionLink("About this Website", "About")

useful Razor helpers: 

  • Web Grid
  • Web Graphics
  • Google Analytics
  • Facebook Integration
  • Twitter Integration
  • Sending Email
  • Validation
Razor supports both C# (C sharp) and VB (Visual Basic)

Razor Syntax Rules for C# 
  • Razor code blocks are enclosed in @{ ... }
  • Inline expressions (variables and functions) start with @
  • Code statements end with semicolon
  • Variables are declared with the var keyword
  • Strings are enclosed with quotation marks
  • C# code is case sensitive
  • C# files have the extension .cshtml
MVC 
  • The Model represents the application core (for instance a list of database records).
  • The View displays the data (the database records).
  • The Controller handles the input (to the database records).
Web API
Traditionally, Web Services provided a great way of creating connected web applications. SOAP and XML created an excellent solution for creating connected web applications. SOAP is a standard XML based protocol that communicated over HTTP. We can think of SOAP as message format for sending messaged between applications using XML. It is independent of technology, platform and is extensible too. ASP.NET Web services provided an excellent way of creating SOAP based web services.

Problem with SOAP
The SOAP offered an excellent way of transferring the data between the applications. but the problem with SOAP was that along with data a lot of other meta data also needs to get transferred with each request and response. This extra information is needed to find out the capabilities of the service and other meta data related to the data that is being transferred coming from the server. This makes the payload heavy even for small data. Also, Web services needed the clients to create the proxy on their end. These proxies will do the marshaling and un-marshaling of SOAP WSDL and make the communication between the application and the web service possible. The problem with this proxy is that if the service is updated and the proxy on the client is not then the application might behave incorrectly.

Weolcome To REST
REST stands for Representational State Transfer. This is a protocol for exchanging data over a distributed environment. The main idea behind REST is that we should treat our distributed services as a resource and we should be able to use simple HTTP protocols to perform various operations on that resource. 
When we talk about the Database as a resource we usually talk in terms of CRUD operations. i.e. Create, Retrieve, Update and Delete. Now the philosophy of REST is that for a remote resource all these operations should be possible and they should be possible using simple HTTP protocols. 
Now the basic CRUD operations are mapped to the HTTP protocols in the following manner

  • GET: This maps to the R(Retrieve) part of the CRUD operation. This will be used to retrieve the required data (representation of data) from the remote resource.
  • PUT: This maps to the U(Update) part of the CRUD operation. This protocol will update the current representation of the data on the remote server.
  • POST: This maps to the C(Create) part of the CRUD operation. This will create a new entry for the current data that is being sent to the server.
  • DELETE: This maps to the D(Delete) part of the CRUD operation. This will delete the specified data from the remote server. 
Note : if we compare the REST API wit SOAP, we can see the benefits of REST. Firstly only the data will be traveling to and from the server because the capabilities of the service are mapped to the URIs and protocols. Secondly, there is no need to have a proxy at the client end because its only data that is coming and the application can directly receive and process the data. 

Welcome To WCF REST Services
Windows Communication Foundation (WCF) came into existence much later than the web service. It provided a much secure and mature way of creating the services to achieve whatever we were not able to achieve using traditional web services, i.e., other protocols support and even duplex communication. With WCF, we can define our service once and then configure it in such a way that it can be used via HTTP, TCP, IPC, and even Message Queues. We can even configure WCF services to create REST services too i.e. WCF REST Services. 
Problem with WCF REST
The problem with using WCF restful services is that we need to do a lot of configurations in a WCF service to make it a RESTful service. WCF is suited for he scenarios where we want to create a services that should support special scenarios such as one way messaging, message queues, duplex communication or the services that need to conform to WS* specifications. 
But using WCF for creating restful services that will provide fully resource oriented services over HTTP is a little complex. Still WCF is the only option for creating the RESTful services if there is a limitation of using .NET 3.5 framework. 

Weolcome To Web API
Microsoft came up with ASP.NET Web API quite recently to facilitate the creation of RESTful services that are capable of providing fully resource oriented services for a broad range of clients including browsers, mobiles and tablets. ASP.NET Web API is a framework for building REST services easily and in a rather simple way. 
Routing: If we look in the App_Start folder we can find two route config files. One if RouteConfig.cs which will contain the normal routes for the MVC 4.0 application. Other is the WebApiConfig.cs
which contains the routing for the WebAPI controllers. 


public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }

    }
The route template starts with the word api so as to distinguish the that the uri points to an API rather than a page. The controller will be mapped to the Controller class we have seen above. 
The interesting part is that the route does not contain the information for action. The reason for this is that the action information will be coming as a part of HTTP method/action rather than in the uri and thus the uri does not need to know anything about the action here. The third parameter id is the value that will be passed to the action methods. 

View: There are no views or the WebAPI controllers because these controllers will serve the raw data in either xml or json format(based on content negotiation) and they dont need any specific views to be associated with them. 

A Note on Content Negotiation 

Content negotiation means that the client and server will mutually agree on the format of the data that will be transfered between them. If the client wants the data in XML or JSON format then it can specify this
in the header of the HTTP request and the server will serve the data in mentioned option. This option of either having XML format or JSON format returned can be specified as application/xml and application/json


































No comments: