MVC Concepts
MVC Concepts
MVC Concepts
Articles
This article provides some interview questions and answers of MVC, basically covering
most of MVC 2, MVC 3 and MVC 4 topics that are more likely to be asked in job
interviews/tests/exams.
The sole purpose of this article is to sum up important questions and answers that can be
used by developers to brush-up on MVC before they go to an interview including it.
What is MVC?
MVC is a framework pattern that splits an application's implementation logic into three
component roles: models, views, and controllers.
Model: The business entity on which the overall application operates. Many
applications use a persistent storage mechanism (such as a database) to store data.
MVC does not specifically mention the data access layer because it is understood to
be encapsulated by the Model.
View: The user interface that renders the Model into a form of interaction.
Controller: Handles a request from a View and updates the Model that results in a
change of the Model's state.
To implement MVC in .NET we need mainly three classes (View, Controller and the Model).
Explain MVC Architecture?
The architecture is self-explanatory. The browser (as usual) sends a request to IIS, IIS
searches for the route defined in the MVC application and passes the request to the
controller as specified by the route, the controller communicates with the model and
passes the populated model (entity) to View (front end), Views are populated with model
properties, and are rendered on the browser, passing the response to the browser through
IIS via controllers that invoked the specified View.
ASP.NET MVC 2 was released in March 2010. Its main features are:
There were also many API enhancements and "pro" features, based on feedback
from developers building a variety of applications on ASP.NET MVC 1, such as:
ASP.NET MVC 3 shipped just 10 months after MVC 2 in Jan 2011. Some of the top features
in MVC 3 included:
The Razor view engine.
Support for .NET 4 Data Annotations.
Greater control and flexibility with support for dependency resolution and global
action filters.
Better JavaScript support with unobtrusive JavaScript, jQuery Validation, and JSON
binding.
Display Modes.
1. App initialization
2. Routing
3. Improved reusability of views/model. One can have multiple views that can point to
the same model and vice versa.
As per Wikipedia 'the process of breaking a computer program into distinct features that
overlap in functionality as little as possible'. The MVC design pattern aims to separate
content from presentation and data-processing from content.
When we talk about Views and Controllers, their ownership itself explains separate. The
views are just the presentation form of an application, it does not need to know specifically
about the requests coming from the controller. The Model is independent of View and
Controllers, it only holds business entities that can be passed to any View by the controller
as required for exposing them to the end user. The controller is independent of Views and
Models, its sole purpose is to handle requests and pass it on as per the routes defined and
as per the need of rendering the views. Thus our business entities (model), business logic
(controllers) and presentation logic (views) lie in logical/physical layers independent of
each other.
Razor is the first major update to render HTML in MVC 3. Razor was designed specifically
as a view engine syntax. It has one main focus: code-focused templating for HTML
generation. Here's how that same markup would be generated using Razor:
@model MvcMusicStore.Models.Genre
@{ViewBag.Title = "Browse Albums";}
<div class="genre">
<h3><em>@Model.Name</em> Albums</h3>
<ul id="album-list">
@foreach (var album in Model.Albums)
{
<li>
<a href="@Url.Action("Details", new { id = album.AlbumId })">
<img alt="@album.Title" src="@album.AlbumArtUrl" />
<span>@album.Title</span>
</a>
</li>
}
</ul>
</div>
The Razor syntax is easier to type, and easier to read. Razor doesn't have the XML-like
heavy syntax of the Web Forms view engine.
Unobtrusive JavaScript is a general term that conveys a general philosophy, similar to the
term REST (Representational State Transfer). The high-level description is that
unobtrusive JavaScript doesn't intermix JavaScript code in your page markup. For example,
rather than hooking in via event attributes like onclick and onsubmit, the unobtrusive
JavaScript attaches to elements by their ID or class, often based on the presence of other
attributes (such as HTML5 data-attributes).
It's got semantic meaning and all of it; the tag structure, element attributes and so on
should have a precise meaning. Strewing JavaScript gunk across the page to facilitate
interaction (I'm looking at you, -doPostBack!) harms the content of the document.
MVC 3 included JavaScript Object Notation (JSON) binding support via the new
JsonValueProviderFactory, enabling the action methods to accept and model-bind data in
JSON format. This is especially useful in advanced Ajax scenarios like client templates and
data binding that need to post data back to the server.
MVC 3 introduced a new concept called a dependency resolver, that greatly simplified the
use of dependency injection in your applications. This made it easier to decouple
application components, making them more configurable and easier to test.
Display modes use a convention-based approach to allow selecting various views based on
the browser making the request. The default view engine first looks for views with names
ending with ".Mobile.cshtml" when the browser's user agent indicates a known mobile
device. For example, if we have a generic view titled "Index.cshtml" and a mobile view titled
"Index.Mobile.cshtml" then MVC 4 will automatically use the mobile view when viewed in a
mobile browser.
Additionally, we can register your own custom device modes that will be based on your
own custom criteria, all in just one code statement. For example, to register a WinPhone
device mode that would serve views ending with ".WinPhone.cshtml" to Windows Phone
devices, you'd use the following code in the Application_Start method of your Global.asax:
"BundleConfig.cs" in MVC4 registers bundles used by the bundling and minification system.
Several bundles are added by default, including jQuery, jQueryUI, jQuery validation,
Modernizr, and default CSS references.
This is used to register global MVC filters. The only filter registered by default is the
HandleErrorAttribute, but this is a great place to put other filter registrations.
"RouteConfig.cs" holds the granddaddy of the MVC config statements and Route
configuration.
Used to register Web API routes, as well as set any additional Web API configuration
settings.
What's new for adding a controller in a MVC 4 application?
Previously (in MVC 3 and MVC 2), the Visual Studio Add Controller menu item only
displayed when we right-clicked on the Controllers folder. However, the use of the
Controllers folder was purely for organization. (MVC will recognize any class that
implements the IController interface as a Controller, regardless of its location in your
application.) The MVC 4 Visual Studio tooling has been modified to display the Add
Controller menu item for any folder in your MVC project. This allows us to organize
controllers however you would like, perhaps separating them into logical groups or
separating MVC and Web API controllers.
Windows XP
Windows Vista
Windows 7
Windows 8
MVC 4 development tooling is included with Visual Studio 2012 and can be installed on
Visual Studio 2010 SP1/Visual Web Developer 2010 Express SP1.
What are the various types of Application Templates used to create an MVC application?
1. The Internet Application template: This contains the beginnings of an MVC web
application, enough that you can run the application immediately after creating it
and see a few pages. This template also includes some basic account management
functions that run against the ASP.NET Membership.
2. The Intranet Application template: The Intranet Application template was added
as part of the ASP.NET MVC 3 Tools Update. It is similar to the Internet Application
template, but the account management functions run against Windows accounts
rather than the ASP.NET Membership system.
3. The Basic template: This template is pretty minimal. It still has the basic folders,
CSS, and MVC application infrastructure in place, but no more. Running an
application created using the Empty template just gives you an error message.
Why use Basic template? The Basic template is intended for experienced MVC
developers who want to set up and configure things exactly how they want them.
4. The Empty template: The Basic Template was previously called the Empty
Template, but developers complained that it wasn't quite empty enough. With MVC
4, the previous Empty
Template was renamed Basic, and the new Empty Template is about as empty as
possible.
It has the assemblies and basic folder structure in place, but that's about it.
6. The Web API template: The ASP.NET Web API is a framework for creating HTTP
services.
The Web API template is similar to the Internet Application template but is
streamlined for Web API development. For instance, there is no user account
management functionality, since Web API account management is often significantly
different from standard MVC account management. Web API functionality is also
available in the other MVC project templates, and even in non-MVC project types.
What are the default Top-level directories created when adding a MVC 4 application?
/Views: For UI template files that are responsible for rendering output like HTML
/Content: For CSS and other site content, other than scripts and images
/App_Start: For configuration code of features like Routing, Bundling, Web API.
Note: Some of the content has been taken from various books/articles.
This namespace contains classes and interfaces that support the MVC pattern for ASP.NET
Web applications. This namespace includes classes that represent controllers, controller
factories, action results, views, partial views, and model binders.
The System.Web.Mvc.Html namespace contains classes that help render HTML controls in
an MVC application. This namespace includes classes that support forms, input controls,
links, partial views, and validation.
MVC provides ViewData, ViewBag and TempData for passing data from the controller, view
and in subsequent requests as well. ViewData and ViewBag are similar to some extent but
TempData performs additional roles.
What are the roles and similarities between ViewData and ViewBag?
Maintains data when moving from controller to view.
Passes data from the controller to the respective view.
Their value becomes null when any redirection occurs, because their role is to
provide a way to communicate between controllers and views. It's a communication
mechanism within the server call.
What are the differences between ViewData and ViewBag (taken from a blog)?
ViewData requires typecasting for complex data types and checks for null values to
avoid error.
NOTE: Although there might not be a technical advantage to choosing one format over the
other, there are some critical differences to be aware of between the two syntaxes.
One obvious difference is that ViewBag works only when the key being accessed is a valid
C# identifier. For example, if you place a value in ViewData["KeyWith Spaces"] then you
can't access that value using ViewBag because the code won't compile.
Another key issue to be aware of is that dynamic values cannot be passed in as parameters
to extension methods. The C# compiler must know the real type of every parameter at
compile time in order for it to choose the correct extension method.
If any parameter is dynamic then compilation will fail. For example, this code will always
fail: @Html.TextBox("name", ViewBag.Name). To work around this, either use
ViewData["Name"] or cast the value to a specifi c type: (string) ViewBag.Name.
What is TempData?
TempData is a dictionary derived from the TempDataDictionary class and stored in a short-
lived session. It is a string key and object value.
It maintains the information for the duration of an HTTP Request. This means only from
one page to another. It helps to maintain data when we move from one controller to
another controller or from one action to another action. In other words, when we redirect
Tempdata, it helps to maintain the data between those redirects. It internally uses session
variables. Temp data used during the current and subsequent request only means it is used
when we are sure that the next request will be redirecting to the next view. It requires
typecasting for complex data types and checks for null values to avoid errors. Generally it is
used to store only one-time messages, like error messages and validation messages.
How can you define a dynamic property using viewbag in ASP.NET MVC?
Assign a key name with the syntax "ViewBag.[Key]=[ Value]" and value using the equal to
operator.
For example, you need to assign a list of students to the dynamic Students property of
ViewBag as in the following:
Note: Some of the content has been taken from various books/articles.
Accepted A view model represents data that you want to have displayed on your
view/page.
Let's say that you have an Employee class that represents your employee domain model
and it contains the following 4 properties:
View models differ from domain models in that view models only contain the data
(represented by properties) that you want to use on your view. For example, let's say that
you want to add a new employee record, your view model might look like this:
As you can see it only contains 2 of the properties of the employee domain model. Why is
this you may ask? Id might not be set from the view and it might be auto-generated by the
Employee table. And DateCreated might also be set in the Stored Procedure or in the
service layer of your application. So Id and DateCreated is not needed in the view model.
When loading the view/page, the create action method in your employee controller will
create an instance of this view model, populate any fields if required, and then pass this
view model to the view:
Your view might look like this (assuming you are using ASP.NET MVC3 and razor):
@model MyProject.Web.ViewModels.ProductCreateViewModel
<table>
<tr>
<td><b>First Name:</b></td>
<td>@Html.TextBoxFor(x => x.FirstName, new { maxlength = "50", size = "50" })
@Html.ValidationMessageFor(x => x.FirstName)
</td>
</tr>
<tr>
<td><b>Last Name:</b></td>
<td>@Html.TextBoxFor(x => x.LastName, new { maxlength = "50", size = "50" })
@Html.ValidationMessageFor(x => x.LastName)
</td>
</tr>
</table>
Validation would thus be done only on FirstName and LastName. Using Fluent Validation
you might have validation like this:
public class CreateEmployeeViewModelValidator :
AbstractValidator<CreateEmployeeViewModel>
{
public CreateEmployeeViewModelValidator()
{
RuleFor(x => x.FirstName)
.NotEmpty()
.WithMessage("First name required")
.Length(1, 50)
.WithMessage("First name must not be greater than 50 characters");
RuleFor(x => x.LastName)
.NotEmpty()
.WithMessage("Last name required")
.Length(1, 50)
.WithMessage("Last name must not be greater than 50 characters");
}
}
The key thing to remember is that the view model only represents the data that you want
to use. You can imagine all the unnecessary code and validation if you have a domain model
with 30 properties and you only want to update a single value. Given this scenario you
would only have this one value/property in the view model and not the entire domain
object.
The solution is independed of the MVC.NET framework and is global across server side
technologies. Most modern AJAX applications utilize XmlHTTPRequest to send async
requests to the server. Such requests will have a distinct request header:
X-Requested-With = XMLHTTPREQUEST
MVC.NET provides helper functions to check for ajax requests that internally inspects the
"X-Requested-With" request header to set the "IsAjax" flag.
What are Scaffold templates?
These templates use the Visual Studio T4 templating system to generate a view based on
the model type selected. Scaffolding in ASP.NET MVC can generate the boilerplate code we
need to create, read, update, and delete (CRUD) functionality in an application. The
scaffolding templates can examine the type definition for it then generate a controller and
the controller's associated views. The scaffolding knows how to name controllers, how to
name views, what code needs to go to each component, and where to place all these pieces
in the project for the application to work.
Empty: Creates an empty view. Only the model type is specified using the model
syntax.
Create: Creates a view with a form for creating new instances of the model.
Generates a label and input field for each property of the model type.
Delete: Creates a view with a form for deleting existing instances of the model.
Displays a label and the current value for each property of the model.
Details: Creates a view that displays a label and the value for each property of the
model type.
Edit: Creates a view with a form for editing existing instances of the model.
Generates a label and input field for each property of the model type.
List: Creates a view with a table of model instances. Generates a column for each
property of the model type. Make sure to pass an IEnumerable<YourModelType> to
this view from your action method.
The view also contains links to actions for performing the create/edit/delete operations.
Razor <span>@model.Message</span>
Web Forms <span><%: model.Message %></span>
Code expressions in Razor are always HTML encoded. This Web Forms syntax also
automatically HTML encodes the value.
Unlike code expressions that are evaluated and sent to the response, blocks of code are
simply sections of code that are executed. They are useful for declaring variables that we
may need to use later.
Razor
@{
int x = 123;
string y = Ë because.Ë ;
}
Web Forms
<%
int x = 123;
string y = "because.";
%>
The HelperPage.IsAjax property gets a value that indicates whether Ajax is being used
during the request of the Web page.
Namespace: System.Web.WebPages
Assembly: System.Web.WebPages.dll
Request["X-Requested-With"] == "XmlHttpRequest".
This example shows what intermixing text and markup looks like using Razor as compared
to Web Forms:
Razor
Web Forms
In simple terms, a repository basically works as a mediator between our business logic
layer and our data access layer of the application. Sometimes it would be troublesome to
expose the data access mechanism directly to the business logic layer, it may result in
redundant code for accessing data for similar entities or it may result in code that is hard to
test or understand. To overcome these kinds of issues, and to write interface driven and
test driven code to access data, we use the Repository Pattern. The repository makes
queries to the data source for the data then maps the data from the data source to a
business entity/domain object and finally persists the changes in the business entity to the
data source. According to MSDN, a repository separates the business logic from the
interactions with the underlying data source or Web Service. The separation between the
data and business tiers has the following three benefits:
It provides a flexible architecture that can be adapted as the overall design of the
application evolves.
In a Repository we write our entire business logic of CRUD operations using Entity
Framework classes that will not only result in meaningful test driven code but will also
reduce our controller code of accessing data.
How can you call a JavaScript function/method on the change of a Dropdown List in
MVC?
<script type="text/javascript">
function selectedIndexChanged() {
}
</script>
A route is a URL pattern that is mapped to a handler. The handler can be a physical file,
such as an .aspx file in a Web Forms application. A Routing module is responsible for
mapping incoming browser requests to specific MVC controller actions.
Routing within the ASP.NET MVC framework serves the following two main purposes:
It matches incoming requests that would not otherwise match a file on the file
system and maps the requests to a controller action.
It constructs outgoing URLs that correspond to controller actions.
Layouts in Razor help maintain a consistent look and feel across multiple views within our
application. Compared to Web Forms Web Forms, layouts serve the same purpose as
master pages, but offer both a simpler syntax and greater flexibility.
We can use a layout to define a common template for your site (or just part of it). This
template contains one or more placeholders that the other views in your application
provide content for. In some ways, it's like an abstract base class for your views. For
example declared at the top of view as in the following:
@{
Layout = "~/Views/Shared/SiteLayout.cshtml";
}
What is ViewStart?
For group of views that all use the same layout, this can get a bit redundant and harder to
maintain.
The "_ViewStart.cshtml" page can be used to remove this redundancy. The code within this
file is executed before the code in any view placed in the same directory. This file is also
recursively applied to any view within a subdirectory.
@{
Layout = "~/Views/Shared/_Layout.cshtml";
}
Because this code runs before any view, a view can override the Layout property and
choose a different one. If a set of views shares common settings then the
"_ViewStart.cshtml" file is a useful place to consolidate these common view settings. If any
view needs to override any of the common settings then the view can set those values to
another value.
Note: Some of the content has been taken from various books/articles.
HTML helpers are methods we can invoke on the Html property of a view. We also have
access to URL helpers (via the URL property) and AJAX helpers (via the Ajax property). All
these helpers have the same goal, to make views easy to author. The URL helper is also
available from within the controller.
Most of the helpers, particularly the HTML helpers, output HTML markup. For example, the
BeginForm helper is a helper we can use to build a robust form tag for our search
form, but without using lines and lines of code:
What is Html.ValidationSummary?
The ValidationSummary helper displays an unordered list of all validation errors in the
ModelState dictionary. The Boolean parameter you are using (with a value of true) is telling
the helper to exclude property-level errors. In other words, you are telling the summary to
display only the errors in ModelState associated with the model itself, and exclude any
errors associated with a specific model property. We will be displaying property-level
errors separately. Assume you have the following code somewhere in the controller action
rendering the edit view:
The first error is a model-level error, because you didn't provide a key (or provided an
empty key) to associate the error with a specific property. The second error you associated
with the Title property, so in your view it will not display in the validation summary area
(unless you remove the parameter to the helper method, or change the value to false). In
this scenario, the helper renders the following HTML:
<div class="validation-summary-errors">
<ul>
<li>This is all wrong!</li>
</ul>
</div>
Other overloads of the ValidationSummary helper enable you to provide header text and
set specific HTML attributes.
NOTE: By convention, the ValidationSummary helper renders the CSS class validation-
summary-errors along with any specific CSS classes you provide. The default MVC project
template includes some styling to display these items in red, that you can change in
"styles.css".
What is Html.Partial?
The Partial helper renders a partial view into a string. Typically, a partial view contains
reusable markup you want to render from inside multiple different views. Partial has four
overloads:
What is Html.RenderPartial?
The RenderPartial helper is similar to Partial, but RenderPartial writes directly to the
response output stream instead of returning a string. For this reason, you must place
RenderPartial inside a code block instead of a code expression. To illustrate, the following
two lines of code render the same output to the output stream:
@{Html.RenderPartial("AlbumDisplay "); }
@Html.Partial("AlbumDisplay ")
In general, you should prefer Partial to RenderPartial because Partial is more convenient
(you don't need to wrap the call in a code block with curly braces). However, RenderPartial
may result in better performance because it writes directly to the response stream,
although it would require a lot of use (either high site traffic or repeated calls in a loop)
before the difference would be noticeable.
How do you return a partial view from controller?
There are various ways for returning/rendering a view in MVC Razor. For example "return
View()", "return RedirectToAction()", "return Redirect()" and "return RedirectToRoute()".
Conclusion
I hope we covered many of questions to brush-up. Since MVC is very vast now, I know we
have missed a lot stuff too. The content in the question and answer form is also taken from
few renowned books like Professional ASP.NET MVC4 from Wrox and a few of the content
is taken from my MVC articles posted earlier. My future articles will provide interview
questions for EntityFramework too.