I am planning a new mvc 3 application.
I am trying to make things as simple as possible.
Here's my question.
I'm planning on having many different models with different params. I am going to have crud operations for all these models but I don't want to have a view for each one. I would like to have one list view and one edit view.
I know this goes agains the lose coupled style of mvc architecture but It would be very handy just for me to send the view a model and the view would work out what fields to add etc.
Has anyone heard o a way to do this?
MVC has an Html.EditorFor() helper into which you can give a whole model and MVC will generate a form from it. I have not tried whether this works dynamicly when your view's model is type of object and you give concrete objects into it, but it might work.
But for all those headaches you will have in the future with your approach I would strongly suggest for you to try to make your different models into an object hierachy (so you will have inherintance) and compose your views with different partial views based on the model's type.
I have used the last way of doing things sucessfully on many occasions. Something in the lines of (code in your topmost view):
#model Animal
//Show Animal fields
#if(Model is Cat)
{
//show cat specific fields
Html.Partial("_cat", Model);
}
else if(Model is Dog)
{
//show dog specific fields
Html.Partial("_dog", Model);
}
So in your controller you could pass either a Dog, Cat or Animal to this view and what would be rendered is dependent on the Model's type.
Related
I have an MVC3 project I'm working on that has a View with an associated strongly typed view model. I've been tasked with adding an optional section to this view that would contain the data for a second model, about half of which is shared with the first model.
My question is, what is the best way to implement this? Should I just add the object that the optional model represents to the view model and try to map values from there?
If I do it this way, how can I associate the editors with both models?
Adding the optional model to the view model is the best choice, because, unlike ViewBag, it's type safe and you can still leverage the html helpers. Just remember to check the second model for null reference before you render it (since it's optional).
For sharing properties, your view model can have special getters/setters that would mantain both models synchronized internally.
I think I understand what your asking and this is how I have accomplished it in the past.
Add the optional model as a parameter in the view model and then create a partial view that is typed to that optional model. If the criteria is met that allows that partial view to display then you pass the viewmodel.optionalmodel to that partial view.
You just have to be a bit careful about the overlap of parameters causing any headaches (as in null references)
in the tutorials from http://www.vainolo.com/tutorials/ the position of the model is saved in the model. I want to save all data to file and want to get the same view, when I load the file.
Searching for an answer for this question, I got another more important question:
Is the GEF really a MVC framework?
GEF Controllers tells the mvc controller role is taken from the EditPart. It creates the specified objects.
Regarding the examples the controller holds view parts, but the mvc pattern tells, that the controller only reacts on user interaction and tells the view, it has to update or what ever.
Concluding on it the following code is wrong, because it is part of EditPart and it changes:
public void refreshVisuals(){
IPersonFigure figure = (IPersonFigure)getFigure();
Person model = (Person)getModel();
figure.setName(model.getName());
figure.setSurname(model.getSurname());
}
Regarding wikipedia the view has an observer on the model, so the following sentence from GEF is wrong, isn't it?
The EditPart syncs the actual model state to the view and implements the observer.
In the MVC pattern, the controllers must listen to the changes of the model. In GEF, EditParts are the controllers so they must listen to their model to update the view according to the new state of the model.
So what is correct?
To prevent cross-posting have a look on http://www.eclipse.org/forums/index.php/m/755178/.
The wikipedia states a the start of the article on MVC that " MVC comes in different flavors (MVC overview). Sometimes the view can read the model directly and update itself, sometimes this is done by the controller.
The primary concept that MVC provides is decoupling the presentation from the view, which should contain no logic. Changes to the model are executed by the controllers, and changes to the view are caused when the model is changed. But this does not mean that the controller can't be the one who updates the view when the model changes. Someone has to do it, right? I personally think that having the view directly read from the model is not a good practice since it makes them too dependent, and that model and view should be completely separated. This is great when you have to make changes in your model (for example a field is changed from being real to being calculated) - you don't have to change your view (but you may have to change your controller, but this is normally easier).
Hope this clears things up for you.
Being a relative newcomer to MVC I'm musing over a little problem. I'm developing a page which relies on a collection of my viewmodel objects. All good. But, as the page has relatively complex functionality I need to get at other objects or collections of the main domain model to display in the UI. Admitedly rather more light weight objects. What's the best way to achieve this?
What I do is create a custom class to encapsulate ANY data I need to display in any certain view / action. So for my Admin areas User controller, I have a AdminUserIndexViewModel class that holds my list of user business objects. I also put any other data I need to display into this class.
For my AdminUserEditViewModel (that corresponds to my Admin Area, User Controller, Edit Action) I might have a single User class, which itself has its Roles attached to modify if need be. If you need to put other information like user settings, or preferences, etc...
If they are not part of the viewmodel you are currently working with then you can use Html.Action to call into another controller method to render another inline view through a controllers method.
I think I'm finally starting to get MVC 3, but if someone can validate this approach I'd feel better about it.
I have a website, let's say, and I have models for NormalPage and EventPage. EventPage has an EventDate, but that's the only difference, and let's just say that EventPage inherits from NormalPage if that makes life easier.
Two views handle these two (slightly) different models, one just showing the page, and the other displaying the date and showing a registration form. They have different designs, so different views are in order.
All the tutorials will say "yup, now write two Controllers: Events and Pages". That seems silly - both are just passing the model to a (appropriate) view. I can use a single "Page" controller and choose the appropriate view using reflection, right? typeof(Model), once I've pulled the data from the database, can tell me whether or not I should pull the Event view or the Page view.
Is that dumb, or asking for trouble, or misusing the framework? Thanks.
What do you intend to do with reflection? You don't need to do anything like that to return views dynamically. From any controller action, you can return View("EventView", eventModel) or View("NormalView", normalModel) and it will return that view.
On a different note, I'm not sure what tutorials suggested that it's typical to have one view per controller but it's not. It's typical to have several views and actions in one controller.
The name "view model" suggests that it models the data for the view. That much is obvious. What else can or should go in the view model?
As an example, a view might display a list of items in a shopping cart, fields for customer's credit card info, and fields for customer's billing information. The view model might contain properties for all that OR it might only contain properties for the shopping cart items.
The view model is a class that represents the fields that your view shows/modifies. So for example if you are going to show a shopping cart and customer's credit card all on the same page these properties should all belong to the view model.
You could even put properties like this in your view model if the view is going to show a drop down list of day names:
public IEnumerable<SelectListItem> DayNames
{
get
{
return CultureInfo
.CurrentCulture
.DateTimeFormat
.DayNames
.Select((dayName, index) => new SelectListItem
{
Value = index.ToString(),
Text = dayName
});
}
}
How exactly you use your view models is a judgement call. One developer might have fewer typed ViewModels so they can be reused. Another developer might have more ViewModels, each smaller and more specific to particular actions. And another developer might rely more on ViewData.
If possible, have your view models be well-organized, contain just what the view needs, and consist mostly of light entity objects. If you have a complicated view though, don't be afraid to make a highly customized view model class that will help simplify the view logic. It's okay to make reusable ViewModels that have a little unused data in them, but avoid using just a few one-size-fits-all ViewModels. ViewModels should have just the data needed for that view or very close.