Model, View and Controler in Angular.Js

MODEL:- Logic that deals with storing or retrieving data is part of the  model.

VIEW:- Logic that deals with formatting the data to display to the user is part of the  view.

CONTROLLER:- The  controller  sits  between  the  model  and  the  view and connects them. The controller responds to user interaction, updating the data in the model and providing the view with the data that it requires.

Advertisements

Configure Routes in ASP.Net MVC

ASP.NET MVC routes are responsible for determining which controller method(controller action) to execute for a given URL. They consist of the following properties:
1.Unique name
A name may be used as a specific reference to a given route
2.URL pattern
A simple pattern syntax that parses matching URLs into meaningful segments
3.Defaults
An optional set of default values for the segments defined in the URL pattern
4.Constraints
A set of constraints to apply against the URL pattern to more narrowly define the
URLs that it matches

When the application starts up, ASP.NET MVC discovers all of the application’s controllers by searching through the available assemblies for classes that implement the System.Web.Mvc.IController interface (or derive from a class that implements this interface, such as System.Web.Mvc.Controller) and whose
class names end with the suffix Controller.

When the routing framework uses this list to figure out which controllers it has access to, it chops off the Controller suffix from all of the controller class names. So, whenever you need to refer to a controller, you do
so by its shortened name, e.g., EmployeeController is referred to as Employee, and Home Controller becomes Home.

The default ASP.NET MVC project templates adds the below generic route that uses the following
URL convention to break the URL for a given request into three named segments,
wrapped with brackets ({}): “controller”, “action”, and “id”:
{controller}/{action}/{id}

This route pattern is registered via a call to the MapRoute() extension method that runs
during application startup (located in App_Start/RouteConfig.cs):

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index",
id = UrlParameter.Optional } // Parameter defaults
);

Ex.

 

Programming is easy…. 🙂

Difference Between Razor View Engine and ASPX View Engine

S.No
Razor View Engine
ASPX View Engine
1
What is Razor View Engine ?

Razor Engine is an advanced view engine that was introduced with MVC3.
This is not a new language but it is a new markup syntax that allows
you to combine code and content in a fluid and expressive manner.

What is ASPX View Engine ?


ASPX View Engine (Web Form Engine ) is the default view engine for the Asp.net MVC
that is included with Asp.net MVC from the beginning.

2

File Extensions used with Razor View Engine?


The file extensions used with Razor Engine are different from Web Form
Engine. It has .cshtml (Razor with C#) or .vbhtml (Razor with VB)
extension for views, partial views, editor templates and for
layout pages.


File Extensions used with ASPX View Engine?


The file extensions used with Web Form Engine are also like Asp.net Web
Forms. It has .aspx extension for views, .ascx extension for
partial views & editor templates and .master extension for
layout/master pages.

3

Syntax used for Razor View Engine ?

Razor has new and advance syntax that are compact, expressive and
reduces typing.

Syntax used for ASPX View Engine ?

Web Form Engine has the same syntax like Asp.net Web Forms uses for
.aspx pages .

4

Whether Razor View Engine’s Syntax is simple or complex?


Razor syntax are easy to learn and much clean than Web Form syntax.
Razor uses @ symbol to make the code like as:

@Html.ActionLink(“Login”, “Login”)


Whether ASPX View Engine’s Syntax is simple or complex?
Web
Form syntax are borrowed from Asp.net Web Forms syntax that are
mixed with html and sometimes make a view messy. Webform uses <%
and %> delimiters to make the code like as:

<%:Html.ActionLink(“SignUp”, “SignUp”) %>

ASP.NET MVC request lifecycle

jogendra@.net

All ASP.NET MVC application life cycle starts out like any other website application: with a request to a
URL.

Routing :- ASP.NET Routing framework is at the core of every ASP.NET MVC request.
In simple terms, ASP.NET routing is just a pattern-matching system. At startup,
the application registers one or more patterns with the framework’s route table to tell
the routing system what to do with any requests that match those patterns. When the
routing engine receives a request at runtime, it matches that request’s URL against the
URL patterns registered with it.

When the routing engine finds a matching pattern in its route table, it forwards the
request to the appropriate handler for that request.
Otherwise, when the request’s URL does not match any of the registered route patterns,
the routing engine indicates that it could not figure out how to handle the request by
returning a 404 HTTP…

View original post 2 more words

ASP.NET MVC request lifecycle

All ASP.NET MVC application life cycle starts out like any other website application: with a request to a
URL.

Routing :- ASP.NET Routing framework is at the core of every ASP.NET MVC request.
In simple terms, ASP.NET routing is just a pattern-matching system. At startup,
the application registers one or more patterns with the framework’s route table to tell
the routing system what to do with any requests that match those patterns. When the
routing engine receives a request at runtime, it matches that request’s URL against the
URL patterns registered with it.

When the routing engine finds a matching pattern in its route table, it forwards the
request to the appropriate handler for that request.
Otherwise, when the request’s URL does not match any of the registered route patterns,
the routing engine indicates that it could not figure out how to handle the request by
returning a 404 HTTP status code.

The Model-View-Controller Architecture

The Model-View-Controller pattern is an architectural pattern that encourages strict
isolation between the individual parts of an application. This isolation is also better known
as separation of concerns, or, in more general terms, “loose coupling.”

Architecting applications in a loosely coupled manner brings a number of both shortand
long-term benefits:
1)Development:
Individual components do not directly depend on other components, which means
that they can be more easily developed in isolation. Components can also be readily
replaced or substituted, preventing complications in one component from affecting
the development of other components with which it may interact.

2.Testability:-
Loose coupling of components allows test implementations to stand in for “production”
components. This makes it easier to, say, avoid making calls to a database,
by replacing the component that makes database calls with one that simply returns
static data. The ability for components to be easily swapped with mock representations
greatly facilitates the testing process, which can drastically increase the
reliability of the system over time.

3.Maintenance:-
Isolated component logic means that changes are typically isolated to a small number
of components—often just one. Since the risk of change generally correlates to
the scope of the change, modifying fewer components is a good thing!

So now that we know Model-View-Controller pattern, let us try to define the Model, View and Controller formally:-

Model: The model represents core business logic and data. Models encapsulate the properties
and behavior of a domain entity and expose properties that describe the entity.
Technically,These are the classes that contain data. They can practically be any class that can be
instantiated and can provide some data.

Controllers: The controller, as the name implies, controls the application logic and acts as the coordinator between the view and the model. Controllers receive input from users via the view, then work with the model to perform specific actions, passing the results back to the view.
Technically,These are the classes that will be invoked on user requests. The main tasks of these
are to generate the model class object, pass them to some view and tell the view to generate
markup and render it on user browser.

Views : The view is responsible for transforming a model or models into a visual representation.
In web applications, this most often means generating HTML to be rendered in the user’s browser, although views can be render in many forms. For instance, the same model might be visualized in HTML, PDF, XML, or perhaps even in a spreadsheet. Views should concentrate only on displaying data and should not contain any business logic themselves—the business logic stays in the model, which should provide the view with everything it needs.

Technically,These are simple pages containing HTML and C# code that will use the server side object i.e.
the model to extract the data, tailor the HTML markup and then render it to the client browser.