Tips & Trick ASP.NET MVC.pdf | Model–View–Controller | Widget (Gui)

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 @using (Html.BeginForm("Login", "Auth", FormMethod.Post)) { @Html.TextBoxFor(model => model.Name) @Html.TextBoxFor(model => model.Email) @Html.PasswordFor(model => model.Password) } 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 @using (Html.BeginForm("Login", "Auth", FormMethod.Post)) { @Html.TextBoxFor(model => model.Email) @Html.PasswordFor(model => model.Password) } 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..