I have been evaluating Asp.Net MVC framework for past couple of weeks for our enterprise application. One thing what I am trying to achieve is Master-Details view. As it’s very clear that there is no viewstate and no postback. Now for instance, I am using Products, Customers, Orders and Order Details table from Northwind database and using Asp.Net MVC I want to create a Master - Details view. Basically I don’t want to have separate views(in other words pages) for Order and Order Details. The view should be comprised of Order and Order Details. How should I design my controller and view to achieve this functionality.
Thanks & Regards,
Burhanuddin Ghee Wala
You would want to write a domain-specific viewmodel class that combines all the data from a single Order and its OrderDetails (I'm assuming there's a 1->N relation on Order->OrderDetails, not familiar with Northwind):
public class OrderViewModel
{
public Order Order {get;set;}
public IEnumerable<OrderDetail> OrderDetails{get;set;}
}
Create a View template that binds to this type, rendering the order and the order details themselves on the same page.
In your controller class, write an action method that will populate a single instance of the OrderViewModel class and pass it to the View template.
You should consider putting the order details into a partial view to make your Order view small. You'll also be able to reuse that piece of view somewhere else in your application.
Related
What are the benefits of using ViewModel vs DataContracts when you are building a product? I am looking for pros and cons for both.
Few benefits I can think of using Viewmodel is it can have presentation Logic,
If I need to display the full user name, my viewmodel can have full
name which is concatenation of First Name and Last Name from
Contracts.
I can mention Data Annotations Like Required and
DisplayName which are view specific.
In Visual Studio I can simply click Add View in controller action and generate view using scaffolding.
Any other benefits? The Guideline in my team is to use DataContracts instead. So I need more details to convince.
They aren't really used for the same thing. ViewModels are used to structure how members in the class are presented on the View. DataContracts are used to pass data between things like Services and websites. View Models are a way of separating the entity model from a display model, that way you can model data from a database and not have it coupled to your view layer.
when your data contract separate from your viewmodel your product has more flexibility to change presentation layer to another .for example you use datacontract as viewmodel in a wpf application .if you want use mvvm you have to change your datacontract struct and implement INotifypropertyChange for call RaisePropertyChanged method in properties set.now you want have a web application too .do you need to call RaisePropertyChanged in web application?!!(it's just a sample).when you use viewmodels you don't worry about datacontracts when change your presentation layer .
I'm starting to develop a new ASP.NET MVC application, and I'd like to make sure that my understanding about the way of developing applications under MVC pattern is correct.
Question 1: Suppose that I have some main views (MainView1, MainView2, ...) with some partial views in it (PartialView1, PartialView2, PartialView3, ...). From what I have understood about MVC, I should define a Model for each view. e.g. I have to define PartialModel, PartialModel2, ... and also define my main models which are containers of the partial models which have been used in them:
public class MainModel1
{
public PartialModel1 Partial1 {get;set}
public PartialModel2 Partial2 {get;set}
public PartialModel3 Partial3 {get;set}
}
This way when I want to redirect to MainView, I can initialize the models used in that view by using this Model. Is my understanding of MVC correct? Or should communication between Views and Models be in another form in MVC?
Question 2: If the above is correct, Then suppose I have a partial view in some of my main view pages. This partial view has a submit button which calls an action method. This action method should somehow return the main page's view with the right viewmodels for views. Is there any recommendation about how to get/set viewmodels of other views in a partial view's action?
Thanks.
You understanding is correct. Each view (no matter whether it is main or partial) should have a corresponding view model (unless in the very rare case where this view contains only static html of course). And following this logic a main view that has to render other partial views will have a view model which itself will have reference (maybe as properties) to view models that are required by those partial views.
There is another technique which is using the Html.Action helper. In this case the partial is rendered through another controller/action than the main one. So you don't need to reference the partial view model in the main view model. They will be completely distinct. Take a look at the following blog post to learn more about Html.Action.
Your understanding is perfectly fine. This is what you can also refer to ViewModel in Asp.net MVC.
So, What basically is an Asp.net MVC ViewModel ?
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
I am trying to come up with a clean design for this -
I am using MVC to process orders, so I have an 'order' entity, with its own controller and views.
From the Create Order view I would like the user to add a 'Customer' entity. I have a controller and CRUD operations for 'customer'.
When someone creates a new Order I would like them to either
1) enter a customer name to see if that customer already exists, and if so, add that Customer to the Order, or
2) Create a new Customer then add that new Customer to the Order.
My problem is I am not sure of a good way to access the Customers from within the Order.
-do I create a partial view for Create Customer, then use that view in the Customer Create AND Order Create?
-then would I create a partial view 'SearchCustomers' that passes params to an action on Customer controller and that returns results? Would I be able to reuse this across the site?
You can see I am not sure about a few things - are partial views the way to reuse things? can partial views be reused across controllers and access different controllers from the ones theyre in?
I have gone through an MVC book and online tutorials but they all seem to use beginner examples, where Model objects don't contain other Model objects.
Thanks for help
Views never "access controllers".
The flow is:
Controller Action Method -> Creates View Model -> Hands it off to a View -> View displays it -> View can pass sub-models on to other partial views
Decomposing everything into smaller models and partial views (or using Editor templates) is a good approach. You can then assemble those smaller models into a larger view model for a complete page, or you can use the ViewBag to assemble them in a non-strongly typed manner.
I have two views that show roughly the same data, but one is by client while the other is by project. Normally this would be great, as the same display template gets re-used across both views. However, I need the display of those items to be different when they list by client vs by project. However, they already have display templates defined. Is there some way for me to have two display templates for a single type?
edit
Ok, I forgot one important detail that makes this more complicated. While there are individual models (view models) that hold the items for each view, the items themselves are of mixed types (common base class). The display templates are for each of the types of items that can be in the list, so I can't use an attribute on the model.
I suppose I could make individual sub-models to wrap or replace the classes, but that's more duplication and work than I'd prefer.
Does each view have it's own strongly typed view? If so create two different templates, then in each model reference them with the [UIHint] annotation.
Example:
public class ClientModel
{
[UIHint("ClientDisplay")]
public SharedDataModel sharedData { get; set;}
//Other fields below
}
Then do the same thing for Project model. If you're currently using the same model between the two you could wrap them in separate new models and do the same thing.
From what you've asked I believe this is what you're trying to do, I had a little trouble following your question.
The 'RenderPartial()' method in ASP.NET MVC offeres a very low level of functionality. It does not provide, nor attempt to provide a true 'sub-controller' model *.
I have an increasing number of controls being rendered via 'RenderPartial()'. They fall into 3 main categories :
1) Controls that are direct
descendants of a specific page that
use that page's model
2) Controls that are direct
descendants of a specific page that
use that page's model with an
additional key of some type.
Think implementation of
'DataRepeater'.
3) Controls that represent unrelated
functionality to the page they appear
on. This could be anything from a
banner rotator, to a feedback form,
store locator, mailing list signup.
The key point being it doesn't care
what page it is put on.
Because of the way the ViewData model works there only exists one model object per request - thats to say anything the subcontrols need must be present in the page model.
Ultimately the MVC team will hopefully come out with a true 'subcontroller' model, but until then I'm just adding anything to the main page model that the child controls also need.
In the case of (3) above this means my model for 'ProductModel' may have to contain a field for 'MailingListSignup' model. Obviously that is not ideal, but i've accepted this at the best compromise with the current framework - and least likely to 'close any doors' to a future subcontroller model.
The controller should be responsible for getting the data for a model because the model should really just be a dumb data structure that doesn't know where it gets its data from. But I don't want the controller to have to create the model in several different places.
What I have begun doing is creating a factory to create me the model. This factory is called by the controller (the model doesn't know about the factory).
public static class JoinMailingListModelFactory {
public static JoinMailingListModel CreateJoinMailingListModel() {
return new JoinMailingListModel()
{
MailingLists = MailingListCache.GetPartnerMailingLists();
};
}
}
So my actual question is how are other people with this same issue actually creating the models. What is going to be the best approach for future compatibility with new MVC features?
NB: There are issues with RenderAction() that I won't go into here - not least that its only in MVCContrib and not going to be in the RTM version of ASP.NET-MVC. Other issues caused sufficent problems that I elected not to use it. So lets pretend for now that only RenderPartial() exists - or at least that thats what I've decided to use.
Instead of adding things like MailingListSignup as a property of your ProductModel, encapsulate both at the same level in a class like ProductViewModel that looks like:
public class ProductViewModel() {
public ProductModel productModel;
public MailingListSignup signup;
}
Then get your View to be strongly-typed to the ProductViewModel class. You can access the ProductModel by calling Model.productModel, and you can access the signup class using Model.signup.
This is a loose interpretation of Fowler's 'Presentation Model' (http://martinfowler.com/eaaDev/PresentationModel.html), but I've seen it used by some Microsoft devs, such as Rob Conery and Stephen Walther.
One approach I've seen for this scenario is to use an action-filter to populate the data for the partial view - i.e. subclass ActionFilterAttribute. In the OnActionExecuting, add the data into the ViewData. Then you just have to decorate the different actions that use that partial view with the filter.
There's a RenderPartial overload I use that let's you specify a new ViewData and Model:
RenderPartial code
If you look at the previous link of the MVC source code, as well as the following (look for RenderPartialInternal method):
RenderPartialInternal code
you can see that if basically copies the viewdata you pass creating a new Dictionary and sets the Model to be used in the control. So the page can have a Model, but then pass a different Model to the sub-control.
If the sub-controls aren't referred directly from the main View Model, you could do the trick Marc Gravell mentions to add your custom logic.
One method I tried was to use a strongly typed partial view with an interface. In most situations an agregated ViewModel is the better way, but I still want to share this.
<%# Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<IMailingListSignup>" %>
The Viewmodel implements the interface
public class ProductViewModel:IMailingListSignup
Thats not perfect at all but solves some issues: You can still easily map properties from your route to the model. I am not shure if you can have a route parameter map to the properties of MailingListSignup otherwise.
You still have the problem of filling the Model. If its not to late I prefer to do it in OnActionExecuted. I dont see how you can fill a Model in OnActionExecuting.