Model Binder in MVC

  Model Binder in MVC:
    http://msdn.microsoft.com/en-us/library/dd410405%28v=vs.100%29.aspx

"A model binder in MVC provides a simple way to map posted form values to a .NET Framework type and pass the type to an action method as a parameter. Binders also give you control over the deserialization of types that are passed to action methods. Model binders are like type converters, because they can convert HTTP requests into objects that are passed to an action method. However, they also have information about the current controller context."


One item I take for granted when I'm using ASP.NET MVC is the powerful feature that is model binding. Model binding is ASP.NET MVC's mechanism for mapping HTTP request data directly into action method parameters and custom .Net objects. Each time your application receives an HTTP request containing the form's data as a pair of key/value pairs, the ControllerActionInvoker invokes the DefaultModelBinder to transform that raw HTTP request into something more meaningful to you, which would be a .Net object. This just works and I love it. Sometimes you need to customize the default model binding to work a little differently. For example, if you were expecting a strongly typed collection of values posted from a multi select control, the default model binding won't work as expected. I'll demonstrate one workaround for this so your action can expect a strongly typed object, and not just an array of strings.

Open visual studio 2010 and create a new ASP.NET MVC 2 empty web application. The model for this will be simple as I want to illustrate the technique of model binding. Here's the model below:

public class Car

{

      public string Make { get; set; }

       public int Id { get; set; }

       public static List<Car> GetCars()

       {

            return new List<Car>

                           {

                               new Car { Id = 1, Make = "Ford"},

                               new Car { Id = 2, Make = "Holden"},

                               new Car { Id = 3, Make = "Chevrolet"}

                           };

       }

}

Now to fast track things. I've got an action that receives HTTP post request and its signature is below:

 [HttpPost]

public ActionResult PostCars(List<Car> cars)

{

      return Content("Ok");

}

The action's parameter is a generic list of Car objects. If you post the data using a multi select HTML control, the default model binding won't work as expected.

The model binder doesn’t know how to bind the incoming values to a generic list of cars. This is where you can create a custom model binder to do this for you. To create a custom model binder, all that’s required is a class that inherits the IModelBinder interface. From there you implement the BindModel method. Here’s the code below:

public class SelectListModelBinder : IModelBinder

{

        public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)

        {

            // Get the raw attempted value from the value provider

            var incomingData = bindingContext.ValueProvider.GetValue("cars").AttemptedValue;

            return incomingData.Split(new char[1] { ',' }).Select(data => Car.GetCars().FirstOrDefault(o => o.Id == int.Parse(data))).ToList();

        }

}

The incoming data can be viewed thanks to the binding context parameter:

var incomingData = bindingContext.ValueProvider.GetValue("cars").AttemptedValue;

The cars values is being passed into the action through the Request.Forms["cars"] value. From there I return a Car object populated with the values from incoming data. Nice and easy.

To use this function I can either register the model binder in the global.asax file, which means it will available to any action that accept a list of cars:

protected void Application_Start()

{

      AreaRegistration.RegisterAllAreas();

       ModelBinders.Binders.Add(typeof (List<Car>), new SelectListModelBinder());

       RegisterRoutes(RouteTable.Routes);

}

If I wanted to target particular actions, I can prefix the model binder to the parameter:

public ActionResult PostCars([ModelBinder(typeof(SelectListModelBinder))] List<Car> cars)

{

      return Content("Ok");

}

Model binding is a powerful feature in ASP.NET MVC and it can help you out in sticky situations.

All the demo related with mvc please click here


Source of this post:http://www.dotnetcurry.com/showarticle.aspx?ID=584

Bind dropdownlist with data from json using MVC razor

Controller:

 [HttpPost]
        public JsonResult GetStateList()
        {
            var list = new List<System.Web.UI.WebControls.ListItem>() {
            new System.Web.UI.WebControls.ListItem() { Value = "1", Text = "bhopal" },
            new System.Web.UI.WebControls.ListItem() { Value = "2", Text = "Indore" },
            new System.Web.UI.WebControls.ListItem() { Value = "3", Text = "Jablpur" }
         };
            return Json(list);
        }



View:

        $.ajax({
            type: "POST",
            url: "ControllerName/GetStateList",
           contentType: "json",
           dataType: "json",
           success: function (data) {
              var ddlCountrylist=$('#Claims1');//Dropdown List Id
               var items = data;             
               $(items).each(function (index, optionText) {
                                                      $('<option value=' + optionText.Value + '>' + optionText.Text + '</option>').appendTo(ddlCountrylist);
               });              
                           },
            error: function (xhr) {
                alert(xhr.responseText);
            }
        });

CSS rule to disable text selection highlighting

<style>

     * {
    -webkit-user-select: none;
    -khtml-user-select: none;
    -moz-user-select: -moz-none;
    -o-user-select: none;
    user-select: none;
     }

</style>

Null coalescing operator

Null coalescing

x ?? y

Evaluates to y if x is null, to x otherwise

Dependency Injection

Dependency Injection (DI) is a software design pattern that allow us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

The Dependency Injection pattern uses a builder object to initialize objects and provide the required dependencies to the object means it allows you to "inject" a dependency from outside the class. 


For example, Suppose your Client class needs to use a Service class component, then the best you can do is to make your Client class aware of an IService interface rather than a Service class. In this way, you can change the implementation of the Service class at any time (and for how many times you want) without breaking the host code.

 

We have following different ways to implement DI :

Constructor Injection

1. This is the most common DI.
2. Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when instantiating that class.
3. Injected component can be used anywhere within the class.
4. Should be used when the injected dependency is required for the class to function.
5. It addresses the most common scenario where a class requires one or more dependencies.

public interface IService
{
 void Serve();
}
 
public class Service : IService
{
 public void Serve()
 {
 Console.WriteLine("Service Called");
 //To Do: Some Stuff
 }
}
 
public class Client
{
 private IService _service;
 
 public Client(IService service)
 {
 this._service = service;
 }
 
 public void Start()
 {
 Console.WriteLine("Service Started");
 this._service.Serve();
 //To Do: Some Stuff
 }
}
class Program
{
 static void Main(string[] args)
 {
 client = new Client(new Service());
 client.Start();
 
 Console.ReadKey();
 }
}
 
 

The Injection happens in the constructor, by passing the Service that implements the IService-Interface. The dependencies are assembled by a "Builder" and Builder responsibilities are as follows:

1. knowing the types of each IService
2. according to the request, feed the abstract IService to the Client

Property injection

1. Also called Setter injection.
2. Used when a class has optional dependencies, or where the implementations may need to be swapped. Different logger implementations could be used this way.
3. May require checking for a provided implementation throughout the class(need to check for null before using it).
4. Does not require adding or modifying constructors.

public interface IService
{
 void Serve();
}
 
public class Service : IService
{
 public void Serve()
 {
 Console.WriteLine("Service Called");
 //To Do: Some Stuff
 }
}
 
public class Client
{
 private IService _service;
 
 public IService Service
 {
 set
 {
 this._service = value;
 }
 }
 
 public void Start()
 {
 Console.WriteLine("Service Started");
 this._service.Serve();
 //To Do: Some Stuff
 }
}
class Program
{
 static void Main(string[] args)
 {
 Client client = new Client();
 client.Service = new Service();
 client.Start();
 
 Console.ReadKey();
 }
}

Method injection

1. Inject the dependency into a single method, for use by that method.
2. Could be useful where the whole class does not need the dependency, just the one method.
3. Generally uncommon, usually used for edge cases.

public interface IService
{
 void Serve();
}
 
public class Service : IService
{
 public void Serve()
 {
 Console.WriteLine("Service Called");
 //To Do: Some Stuff
 }
}
 
public class Client
{
 private IService _service;
 
 public void Start(IService service)
 {
 this._service = service;
 Console.WriteLine("Service Started");
 this._service.Serve();
 //To Do: Some Stuff
 }
}
class Program
{
 static void Main(string[] args)
 {
 Client client = new Client();
 client.Start(new Service());
 
 Console.ReadKey();
 }
}
 
 

Key points about DI

1. Reduces class coupling
2. Increases code reusing
3. Improves code maintainability
4. Improves application testing

What's the difference between SQL Replication and SQL Database Mirror?

A.)

Mirroring:-

The Mirror database is not accessible for read or write access.

Replication:-

The Subscriber Database (backup site) is open to reads and writes.

B.)

Mirroring:-

Information flow will be only one way (from Principal to Mirror Server)

Replication:-

Changes can be merged, bi-directional changes can be made, so the information can flow from Publisher to Subscriber and the other way around.

C.)

Mirroring:-

In case of failure of the Principal Database, the Mirror Database will take over the control and will act as Principal and applications can be redirected automatically to connect to this new Principal Server. Very little downtime. No code change required in the application.

Replication:-

In case of failure on Publisher, applications need to be re-directed to the Subscriber manually (in case you really want to do that), requires code change in the app or the connection string.

D.)

Mirroring:-

Almost everything inside the DB is replicated to the DR site, Schema changes can be replicated easily.

Replication:-

You have the option to replicate selected set of tables/SP/functions inside the DB, Schema changes can give some hiccups.

In Short, Mirroring is a good tool for DR (Disaster Recovery) with very little downtime, but the drawback is that the DR site will *not* be accessible to users, whereas Replication can be used to Merge Data between two Servers, can act as a good tool for Reporting purposes as the backup site is accessible to the users, can also act a DR solution.

It all depends on what you need, what are the business requirements , which will help you to choose the right topology in your environment. You can go through SQL Books Online for more details about Mirroring and Replication.

Difference between Row_Number, Rank, Dense_Rank in Sql Server

Row_Number

Returns the sequential number of a row within a partition of a result set, starting at 1 for the first row in each partition.

ROW_NUMBER ( ) OVER ([<partition_by_clause>] <order_by_clause>)

Rank 
Returns the rank of each row within the partition of a result set.<br/> The rank of a row is one plus the number of ranks that come before the row in question.

RANK ( )    OVER ([< partition_by_clause >] < order_by_clause >)

Dense_Rank

 Returns the rank of rows within the partition of a result set,<br/> without any gaps in the ranking. The rank of a row is one plus the number of distinct ranks that come before the row in question.

DENSE_RANK ( )    OVER ([<partition_by_clause> ] < order_by_clause > )

NTILE 

Distributes the rows in an ordered partition into a specified number of groups. <br/>The groups are numbered, starting at one. For each row, NTILE returns the number of the group to which the row belongs.

NTILE (integer_expression) OVER ([<partition_by_clause>] < order_by_clause >)

Where

<partition_by_clause>

Divides the result set produced by the From clause into partitions to which the Row_Number/ Rank/ Dense_Rank/ Ntile function is applied.

<order_by_clause>

Determines the order in which the Row_Number/ Rank/ Dense_Rank/ Ntile values are applied to the rows in a partition.

We will apply these function on the below customer product table CustProd.

name	Product
cust1	decoder
cust2	cable
cust1	cable
cust2	package
cust3	decoder
cust3	cable

Please see the below snapshot for understanding of these function through example

With partition by product and order by name,

When we use partition by product, then it divides the result on the basis of product, as there are three distinct products then there will be 3 partitions.

After partition, order by name is used, that means, in the partitions Row Number, Rank or Dense Rank will be assigned as per the order of name. Here in the below result we see that rank ,row number and dense rank, all are having same value, It’s because in each partition there are distinct name given, if name would have been repeated for the same product then those records will have same rank and dense rank, but row number would have been same as shown below.

When used order by product instead of name, then we see in the below result that, the Rank and dense Rank were 1, Because we did partition of result by product , that means there will be common product in each partition , and rank and dense rank will also be same for same product.