You should always create separate ViewModels for your views. There should be an abstraction from your Views to your Domain Models. In the demos/tutorials they show it all pretty and easy by simply strongly typing the Views to Domain Models but that's not a good strategy. The views should not be dependent on the business objects.
You should implement David Glenn's proposed solution for your current scenario and also for all other views even if requires mapping the domain model to to another view model class.
If you have lets say a top Menu > TopMenu.aspx
And you have multiple partial views inside it > StudentMenu.ascx, ResultMenu.ascx
You will create a View Model for Top Menu > TopMenuViewModel.cs
And you will also create view models for partial views > StudentMenuViewModel , ResultMenuViewModel etc.
and your TopMenuViewModel will have both >
//all the stuff required in TopMenu.aspx
and in TopMenu.aspx when rendering the partial you will pass the relevant view model >
Yup mostly but if you are building a large project, you should always be abstracting your domain objects and view models.
Hi thanks for the tip, that's the plan from the start to separate the domain models. But I get confuse on how will I send the model objects from the controller, specially when I divided my page into several partial views. And some partial views depend on certain models. For example in my partial view menu, assuming I have a MenuViewModel. Add the MenuViewModel in a match bigger model CompilationViewModel (menu, students, etc), how will I access that particular view model in a given view? Or much worse access 2 view models in a single view? Thanks.
Hi, thanks for the sample code. It sure is helpful, I just thought I could get away without passing the model from the main view, just access the view model directly from the partial view.