Tips & Trick ASP - NET MVC PDF

Some Notes:
"When should I use a ViewBag vs. ViewData vs. TempData objects?" -- a frequent question in online
forums, during presentations, and at events. There are enough similarities and differences between these
objects that warrant a closer look to see exactly how you can use each of these objects while developing
MVC applications.
All three objects are available as properties of both the view and controller. As a rule of thumb, you'll use
the ViewData, ViewBag, and TempData objects for the purposes of transporting small amounts of data
from and to specific locations (e.g., controller to view or between views). Both the ViewData and ViewBag
objects work well in the following scenarios:
Incorporating dropdown lists of lookup data into an entity
Components like a shopping cart
Widgets like a user profile widget
Small amounts of aggregate data
While the TempData object works well in one basic scenario:
Passing data between the current and next HTTP requests
If you need to work with larger amounts of data, reporting data, create dashboards, or work with multiple
disparate sources of data, you can use the more heavy duty ViewModel object.
References: http://rachelappel.com/when-to-use-viewbag-viewdata-or-tempdata-in-asp.net-mvc-3applications
In ASP.NET MVC, ViewModels allow you to shape multiple entities from one or more data models or
sources into a single object, optimized for consumption and rendering by the view. The below image
illustrates the concept of a ViewModel:
The purpose of a ViewModel is for the view to have a single object to render, alleviating the need for UI
logic code in the view that would otherwise be necessary. This means the only responsibility, or concern,
of the view is to render that single ViewModel object, aiding in a cleaner separation of concerns (SoC).
Concerns are distinct aspects of the application that have a particular purpose (i.e., concern), and keeping
these aspects apart means your application is more organized, and the code more focused. Putting data
manipulation code in its own location away from the view and controller, enforces SoC.
Using ViewModels in MVC for finer granularity and better SoC leads to more easily maintainable and
testable code. Remember, unit testing is about testing small units.
Along with better coding practices, there are many business reasons demonstrating why you might
consider using ViewModels:
Incorporating dropdown lists of lookup data into a related entity
Master-detail records view
Pagination: combining actual data and paging information
Components like a shopping cart or user profile widget
Dashboards, with multiple sources of disparate data
Reports, often with aggregate data
References: http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.netmvc-applications
How to render multiple model into single view page in ASP.NE T MVC? Nice answer from
http://stackoverflow.com/questions/4764011/multiple-models-in-a-view
First opinion:
I'd recommend using Html.RenderAction and PartialViewResults to accomplish this; it will allow
you to display the same data, but each partial view would still have a single view model and removes
the need for a BigViewModel
So your view contain something like the following:
@Html.RenderAction("Login")
@Html.RenderAction("Register")
Where Login & Register are both actions in your controller defined like the following:
public PartialViewResult Login( )
{
return PartialView( "Login", new LoginViewModel() );
}
public PartialViewResult Register( )
{
return PartialView( "Register", new RegisterViewModel() );
}
The Login & Register would then be user controls residing in either the current View folder, or in
the Shared folder and would like something like this:
/Views/Shared/Login.cshtml: (or /Views/MyView/Login.cshtml)
@model LoginViewModel
@using (Html.BeginForm("Login", "Auth", FormMethod.Post))
{
@Html.TextBoxFor(model => model.Email)
@Html.PasswordFor(model => model.Password)
}
/Views/Shared/Register.cshtml: (or /Views/MyView/Register.cshtml)
@model ViewModel.RegisterViewModel
{
@Html.TextBoxFor(model => model.Name)
}
And there you have a single controller action, view and view file for each action with each totally
distinct and not reliant upon one another for anything.
Second opinion:
There are lots of ways...

1. with your big viewmodel you do:
2. @model BigViewModel
3. @using(Html.BeginForm()) {
4.
@Html.EditorFor(o => o.LoginViewModel.Email)
5.
...
}
6. you can create 2 additional views
Login.cshtml
@model ViewModel.LoginViewModel
{
}
and register.cshtml same thing
after creation you have to render them in the main view and pass them the viewmodel/viewdata
so it could be like this:
@{Html.RenderPartial("login", ViewBag.Login);}
@{Html.RenderPartial("register", ViewBag.Register);}
or
@{Html.RenderPartial("login", Model.LoginViewModel)}
@{Html.RenderPartial("register", Model.RegisterViewModel)}
7. using ajax parts of your web-site become more independent
8. iframes, but probably this is not the case
When to use RenderAction or RenderPartial

There is a big difference between RenderAction and RenderPartial. RenderPartial will render
a View on the same controller (or a shared one), while RenderAction will actually perform an entire
cycle of MVC, that is: it will instantiate the controller (any controller you mention, not just the current
one), it will execute the action, and it will then return and render the result.
The RenderPartial is more similar to an inclusion, it will even share the same model if you don't
specify a different one.
The RenderAction is much more complex (and there may be undesired side effects, that's why they
did not make this function available since version 1 -- initially it was available as an experimental
feature).
So in your case, if you have widgets, it's OK to use both. It depends on the complexity of the widget.
If you have one that has to get data from a DB, do something complex, etc... then you should
probably useRenderAction.
I have a News controller responsible for news objects. I created a Block action, which will render a
block with the latest news to be put in the home page. This is a perfect example, in my opinion, for
RenderAction.
-------------Working with MVC requires much attention to not to shoot yourself in the foot. I mean it by the
efficiency of the MVC products. In complex projects I would prefer to use RenderPartial rather than
RenderAction. I use RenderPartial in which I use jQuery.ajax request (with Html.Action). It definitely
works more efficiently than RenderAction. By this way you can put your Views into cache and then
call jQuery.ajax. Try it yourselves.
References: http://stackoverflow.com/questions/719027/renderactionrenderpartial/1525767#1525767
How To Create a Paging Table in ASP.NET MVC

References: http://www.codeproject.com/Articles/30588/ASP-NET-MVC-Flexigrid-sample
Some Best Practices:

Is the better to return an empty collection rather than null value. Refers to .NET Framework Design
Guidelines..

Tips & Trick ASP - NET MVC PDF

Uploaded by

Copyright:

Available Formats

Tips & Trick ASP - NET MVC PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tips & Trick ASP - NET MVC PDF

Uploaded by

Copyright:

Available Formats

Some Notes:

Incorporating dropdown lists of lookup data into an entity

Components like a shopping cart

Widgets like a user profile widget

Small amounts of aggregate data

While the TempData object works well in one basic scenario:

Passing data between the current and next HTTP requests

Incorporating dropdown lists of lookup data into a related entity

Master-detail records view

Pagination: combining actual data and paging information

Components like a shopping cart or user profile widget

Dashboards, with multiple sources of disparate data

Reports, often with aggregate data

There are lots of ways...

8. iframes, but probably this is not the case

When to use RenderAction or RenderPartial

How To Create a Paging Table in ASP.NET MVC

Some Best Practices:

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.