Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 20

ASP.

NET MVC

Introduction
The Model-View-Controller (MVC) is a software architecture

pattern where we separate the architecture into three areas.


This separation gives you more control over the individual

parts of the application, which lets you more easily develop,


modify, and test them.
ASP.NET MVC is part of the ASP.NET framework.
ASP.NET MVC is an option , not replacement.

ASP.NET > MVC


ASP.NET > Web Forms

ASP.NET MVC Framework


The ASP.NET framework is one part of the .NET
framework.
The ASP.NET framework is Microsofts framework for
building web applications. It contains a set of classes that
were created specifically to support building web
applications.
ASP.NET framework includes classes for implementing
web page caching, authentication, and authorization.
Microsoft has two frameworks for building web
applications built on top of the ASP.NET framework:
ASP.NET Web Forms and ASP.NET MVC.

Drawbacks of ASP.NET
Display logic coupled with code, through code-behind files
Harder to unit test application logic, because of the coupled

code-behind files
ViewState and PostBack model
State management of controls leads to very large and often

unnecessary page sizes

Advantages of ASP.NET MVC


Provides complete control over your HTML markup.
Clear separation of concerns
Enables Test Driven Development (TDD).
Easy integration with JavaScript frameworks like jQuery
or Yahoo UI frameworks
Enables rich AJAX integration
No ViewState and PostBack model
Supports all the core ASP.NET features, such as
authentication, caching, membership, etc.

ASP.NET Versions.
ASP.NET MVC 1.0 (Dec,2008)
ASP.NET MVC 2.0 Beta (Nov,2009)

ASP.NET MVC 3.0(Present)

Requirements
.NET Framework 3.5
Visual Studio 2008(service pack 1)
Visual Studio 2010(included)

MVC Design Pattern

Model=The

data
structure

View=Wha
t is
presented
to the
client

Model

View

Contro
ll
=Does er
t
proces he
sing
Controlle
r

MVC :MODEL-VIEW-CONTROLLER
HTTP
Request
Browser

Controller

Executio
n
Paramete
rs
Resulting
Data
Arrays

HTTP
Response

Resulting
Data
Arrays

GUI
Content
View

Model

ASP.NET MVC Default Project Structure

This diagram represents the

ASP.NET

MVC

default

project

structure.
Default project has Global.asax
file which includes the routing
information

for

default

application.
The following are the default
folders that will come when new
MVC project is created.

Directory
/Controllers
requests

Purpose
Where you put Controller classes that handle URL

/Models
Where
manipulate data
/Views

you

put

classes

that

represent

and

Where you put UI template files that are responsible for


rendering output

/Scripts
(.js)

Where you put JavaScript library files and scripts

/Content Where you put CSS and image files, and other nondynamic/non-JavaScript content
/App_Data Where you store data files you want to read/write.

When we run an ASP.NET MVC application, Visual Studio


launches the application in your web browser.
Below is the home page for our new project (URL: "/)

MVC Routing
Generally routing information is given in Global.asax file.
namespace MvcApplication1
{
public class MvcApplication : System.Web.HttpApplication
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
// Route name
"{controller}/{action}/{id}",
// URL with
parameters
new { controller = "Home", action = "Index", id = "" }
//Parameter defaults
);
}
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
}

The Default route maps the first segment of a URL to a controller


name,
the second segment of a URL to a controller action, and
the third segment to a parameter named id.
Imagine that you enter the following URL into your web browser's
address bar:
/Home/Index/3
The Default route maps this URL to the following parameters:
Action method
controller = Home
in controller
action = Index
id = 3
http://localhost:49450/Account/Sig
Example
nIn
Schem
Host
Controller
a

Controller
MVC controllers are responsible for responding to requests
made against an ASP.NET MVC website. Each browser
request is mapped to a particular controller.
A set of action methods that share a common Controller
context.
An Action:
Receives the request parameters.
Creates any required model (user, etc..).
Calls services or repositories to execute data or get the
models to be displayed.
Selects the view and sends the model to it.

Example:
http://localhost:49450/Home/Index
namespace MvcApplication1.Controllers
{
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["Title"] = "Home Page";
ViewData["Message"] = "Welcome to ASP.NET MVC!;
return View();
}
public ActionResult About()
{
ViewData["Title"] = "About Page;
return View();
}
}
}

View
Just renderer
No logic should go there
Code Behind exists but not recommended
No ViewState, No Server Controls
Takes the view data from the controller.
Can be typed.(strongly typed i.e. model is included)

View Example
Index.aspx.
<%@ Page Language="C#"
MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>
<asp:Content ID="aboutContent"
ContentPlaceHolderID="MainContent" runat="server">
<h2><% : ViewData[Message"] %></h2>
<p>
Put content here.
</p>
</asp:Content>

Model
An MVC model contains all of our application logic that is not
contained in a view or a controller.
The model should contain all of our application business logic,
validation logic, and database access logic.
For example, if you are using the Microsoft Entity Framework
to access your database, then you would create your Entity
Framework classes (your .edmx file) in the Models folder.
A view should contain only logic related to generating the user
interface. A controller should only contain the bare minimum of
logic required to return the right view or redirect the user to
another action (flow control). Everything else should be
contained in the model.

Our controller methods should contain only a few lines of code.


If a controller action gets too fat, then you should consider
moving the logic out to a new class in the Models folder.

Example
namespace MvcApplication1.Models
{
public class HomeModel
{
}
public class Users
{
// Database connections will go here..
public int UserId { set; get; }
public string Name { set; get; }
public string Address { set; get; }
// Database operations will go here..
}
}

Thank Q
Any
Questions??

You might also like