The Model-View-Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller. The ASP.NET MVC framework provides an alternative to the ASP.NET Web Forms pattern for creating Web applications. The ASP.NET MVC framework is a lightweight, highly testable presentation framework that (as with Web Forms-based applications) is integrated with existing ASP.NET features, such as master pages and membership-based authentication. The MVC framework is defined in the System.Web.Mvc assembly.

The MVC framework includes the following components:

• Models. Model objects are the parts of the application that implement the logic for the application's data domain. Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in a SQL Server database. In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a dataset and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the dataset takes on the role of a model object.
• Views. Views are the components that display the application's user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Product object.
• Controllers. Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn might use these values to query the database.

To try to create instance in the action, the bind model process will search data in various places:

• Form Data
• Route Data
• Query String
• Files Custom (cookies for example)

ASP.NET Razor includes view engines for both C# and VB.

The C# view engine processes files with a .cshtml extension, while the VB view engine works with .vbhtml files.

By default, Safari does not enforce HTML5 element validation. You need to override this manually using other means.

An ActionResult is best though of as an web endpoint in MVC. Ever ActionResult method can be reached by typing in the appropriate web address as configured by your Routing engine.

if you want to go to this area through your default controller

      return RedirectToAction("Index","Home",new{area="areaname"});

The whole point of Dependency Injection ( DI ) is to reduce code coupling. Imagine any kind if interaction which involves newing up something like in the "Hard coded dependency example".

A big part of writing code is the ability to test it. Every time we new up a new dependency, we make our code difficult to test because we have no control over that dependency.

How would you test code which depends on DataTime.Now for example? It always changes so you have no reference. This is when you inject a stable parameter as your starting point. You can control it, you can write tests based on various values and make sure you always get the right result.

A good option therefore is to pass an interface or an abstract class as a parameter in the constructor DI.

An interface represents a well defined contract, you can always rely on the methods to be there and you can always rely on the method signatures.

Once you start using DI other aspects will open up. For example, even if you pass an interface at some point you will need a real implementation to actually do any work. This is where other concepts appear. We can use IOC ( Inversion of Control ) to resolve our dependencies. This means that we instruct our code to always use a specific implementation for any contract. Of course there are other ways of doing this. We could always instantiate each contract with a specific implementation and from that point onwards our code can use that part :

public ILogging Logging { get; set }

at some point we initialise it.

Logging = new FileLogging();

this will always work as long as our class fulfils the expected contract :

public class FileLogging : ILogging

from the initialise moment onwards we always use the Logging object. This makes lif easier because if we ever decide to change and use a DatabaseLogging for example, we only have to change the code in one place and this is exactly where we initialise the Logging class.

Is DI only good for testing? No, DI is important when writing maintainable code as well. It allows the separation of concerns to be clear.

When you write any code, think ... is it testable, can I write a test, that's when injecting a DateTime value instead of using DateTime.Now makes sense.

The package Jquery.Unobtrusive-Ajax is required in the project. The corresponding javascript files must be included in a bundle (jquery.unobtrusive-ajax.js or jquery.unobtrusive-ajax.min.js). Finally, it must be activated as well in the web.config file:

<appSettings>
    <add key="UnobtrusiveJavaScriptEnabled" value="true" />
</appSettings>

The Actions invoked (SomeAction in the examples) must either return a Json or a PartialView.