Best Practices for MVC.. ViewModel Binding using Interfaces Example - asp.net

I am new to ASP.NET MVC 3.0 and trying to build an application using the MVC ViewModel design..
I was wondering what the best practices are regrading controllers for ViewModels and have a few questions below.. This is my understanding so far (which might be wrong)..
We create Models.
Create ViewModels by making a new class and declairing attributes with the same name and type as the base model classes (including ID fields of the base models you want to update later.. and the classes are not linked in any way).
Create a Repository for each of the base models (to find and save data ect.).
Create a Controller action for each of the ViewModels (which access the repositories of the base classes to retrieve values and put these values into the ViewModel, then pass the ViewModel to the ViewModels View).
Create Views from the ViewModels (ViewModel Views)
In the ViewModel controller Update (POST) method recieve the updated ViewModel object and convert it into base model objects (Maybe use Automapper?) and next save the base model objects back using their repositories and apply binding like this? "TryUpdate<'IPerson>(person)", "TryUpdate<'IPlace>(place);" (this looks wrong, the aim is to put the values back into the base classes from the ViewModel, apply binding, save base models back using the repositories!.. This doesnt appear to use the repositories.. Instead of TryUpdate<'IPerson>(person); I would expect to see something like this: person.Save(IPerson).. where "person contains the values", ".Save is the repository", and "IPerson contains the binding attributes to use for binding"?.. Not sure if this is right..
So far I have created ViewModels by making a new class and adding attributes from different base models using the same names. At this point i have the following questions:
Q1: Does each ViewModel have its own controller and access each of the base models repository classes to get its values?
Q2: in the ViewModel should you include the ID field of all of the base models that you are using attributes from, considering that you might want to POST an Update back through the ViewModels Controller to the base Models repository (needing the ID values)?
Q3: How would you bind attributes using an interface for binding the model in the controller using the repository to save.
I have been unable to find a tutorial or resource that explains everything in a step by step example, A complete answer would be the following example:
2x simple models, 1x simple viewModel, 1x interface for binding, 1x simple controller using an interface class for binding on update, 1x repository.. i.e.
//Model1
public class Person
{
int PersonID {get;set;}
string FirstName {get;set;}
string LastName {get;set;}
DateTime DOB {get;set}
}
//Model2
public class Place
{
int PlaceID {get;set;}
string Description {get;set;}
string AreaType {get;set;}
string PostCode {get;set;}
}
//ViewModel (containing attributes from models)
publc class ViewModel
{
//Person attributes
int PersonID {get;set;}
string FirstName {get;set;}
string LastName {get;set;}
//Place attributes
int PlaceID {get;set;}
string Description {get;set;}
string AreaType {get;set;}
//other attributes
string someOtherAttributeForDisplay {get;set}
}
//Model1 interface (for binding on model)
public interface IPerson
{
string FirstName {get;set;}
}
//Model2 interface (for binding on model)
public interface IPlace
{
string Description {get;set;}
string AreaType {get;set}
}
//ViewModelController?
{
//What goes here?
}
//Repository?
{
//what goes here?
}

I think you may have overcomplicated a very simple concept.
First off some general rules:
Don't use TryUpdateModel. Just don't.
For the same reasons, don't use any "auto" mapping mappers to map from your view model to your entities. Auto mapping the other way round (from entity to view model) is fine.
Your use of interfaces is unnecessary.
View models are supposed to be very simple classes that contain just the information you need for your view. If your view POSTs different information from what it displays, then just create a different view model for POST.
We use a naming convention of {Controller}{Action}Model for our view models. So for an action named "List" on a "Post" controller we will have a model called "PostListModel".
Finally, check out my response here Real example of TryUpdateModel, ASP .NET MVC 3

Related

How to create model variables based on database content

What I'm curious to get help with, is setting Model variables based on table data.
For example, In my database I may have a table of Facilities such as:
Toilet int, Sink int, Bath int, Rug string
Really bad example but yeah, these values may change in the database from form input or more facilities maybe added based on user input.
Now for me this isn't a problem, However what I would like to know is; in my model I get; and set; the values for [HttpPost] like this:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Index(NewBooking model)
{
if (!ModelState.IsValid)
{
return View("~/Views/Timetabler/Booking/Index.cshtml", model);
}
return View("~/Views/Timetabler/Booking/Index.cshtml", model);
}
So in my model I don't know what the variables would be, they could be Toilet, Sink etc but they could be somehting else therefore something like this wouldn't be suitable:
namespace build_01.Models.Timetabler
{
public class NewBooking
{
public string Toilet { get; set; }
}
}
How can I, if at all, create my model variables based on database table content?
Might I suggest using Entity Framework to generate database models?
It really is quite simple and if you make a change to the database table, you can update the model in your project.
If you already have a database, you would use a "Database First" approach. Make sure your database tables each have a Primary Key assigned to them.
https://www.asp.net/mvc/overview/getting-started/database-first-development/creating-the-web-application
In your application, right click your 'Models' folder > Add > New Item > ADO.NET Entity Data Model > EF Designer From Database ... Follow the steps on screen from here.
This will generate model classes that match the data types in your database. Oh, if your project doesnt already have Entity Framework, search for it in Nuget or check it on the Nuget repository.
https://www.nuget.org/packages/EntityFramework/

Models, ViewModels, DTOs in MVC 3 application

I have a web solution (in VS2010) with two sub-projects:
Domain which holds the Model classes (mapped to database tables via Entity Framework) and Services which (besides other stuff) are responsible for CRUD operations
WebUI which references the Domain project
For the first pages I've created I have used the Model classes from the Domain project directly as Model in my strongly typed Views because the classes were small and I wanted to display and modify all properties.
Now I have a page which should only work with a small part of all properties of the corresponding Domain Model. I retrieve those properties by using a projection of the query result in my Service class. But I need to project into a type - and here come my questions about the solutions I can think of:
I introduce ViewModels which live in the WebUI project and expose IQueryables and the EF data context from the service to the WebUI project. Then I could directly project into those ViewModels.
If I don't want to expose IQueryables and the EF data context I put the ViewModel classes in the Domain project, then I can return the ViewModels directly as result of the queries and projections from the Service classes.
In addition to the ViewModels in the WebUI project I introduce Data transfer objects which move the data from the queries in the Service classes to the ViewModels.
Solution 1 and 2 look like the same amount of work and I am inclined to prefer solution 2 to keep all the database concerns in a separate project. But somehow it sounds wrong to have View-Models in the Domain project.
Solution 3 sounds like a lot more work since I have more classes to create and to care about the Model-DTO-ViewModel mapping. I also don't understand what would be the difference between the DTOs and the ViewModels. Aren't the ViewModels exactly the collection of the selected properties of my Model class which I want to display? Wouldn't they contain the same members as the DTOs? Why would I want to differentiate between ViewModels and DTO?
Which of these three solutions is preferable and what are the benefits and downsides? Are there other options?
Thank you for feedback in advance!
Edit (because I had perhaps a too long wall of text and have been asked for code)
Example: I have a Customer Entity ...
public class Customer
{
public int ID { get; set; }
public string Name { get; set; }
public City { get; set; }
// ... and many more properties
}
... and want to create a View which only shows (and perhaps allows to edit) the Name of customers in a list. In a Service class I extract the data I need for the View via a projection:
public class CustomerService
{
public List<SomeClass1> GetCustomerNameList()
{
using (var dbContext = new MyDbContext())
{
return dbContext.Customers
.Select(c => new SomeClass1
{
ID = c.ID,
Name = c.Name
})
.ToList();
}
}
}
Then there is a CustomerController with an action method. How should this look like?
Either this way (a) ...
public ActionResult Index()
{
List<SomeClass1> list = _service.GetCustomerNameList();
return View(list);
}
... or better this way (b):
public ActionResult Index()
{
List<SomeClass1> list = _service.GetCustomerNameList();
List<SomeClass2> newList = CreateNewList(list);
return View(newList);
}
With respect to option 3 above I'd say: SomeClass1 (lives in Domain project) is a DTO and SomeClass2 (lives in WebUI project) is a ViewModel.
I am wondering if it ever makes sense to distinguish the two classes. Why wouldn't I always choose option (a) for the controller action (because it's easier)? Are there reasons to introduce the ViewModel (SomeClass2) in addition to the DTO (SomeClass1)?
I would solve your problem by using an auto-mapping tool (like AutoMapper) to do the mapping for you. In cases where the mapping is easy (for example if all properties from one class should be mapped to properties with the same name on another class) AutoMapper will be able to do all the hook-up work for you, and you'll have to give a couple of lines of code to note that there should be a map between the two at all.
That way, you can have your entities in Domain, and a couple of view model classes in your WebUI, and somewhere (preferrably in WebUI or a sub namespace of the same) define maps between them. Your view models will in effect be DTOs, but you won't have to worry much about the conversion process between the domain and your DTO classes.
Note: I would strongly recommend against giving your Domain entities straight to the views of your MVC web UI. You don't want EF to "stick around" all the way to the front-end layer, in case you later want to use something other than EF.
introduce ViewModels which live in the
WebUI project and expose IQueryables
and the EF data context from the
service to the WebUI project. Then I
could directly project into those
ViewModels.
The trouble with this is you soon run into problems using EF trying to 'flatten' models. I encountered something similar when I had a CommentViewModel class that looked like this:
public class CommentViewModel
{
public string Content { get; set; }
public string DateCreated { get; set; }
}
The following EF4 query projection to the CommentViewModel wouldn't work as the couldn't translate the ToString() method into SQL:
var comments = from c in DbSet where c.PostId == postId
select new CommentViewModel()
{
Content = c.Content,
DateCreated = c.DateCreated.ToShortTimeString()
};
Using something like Automapper is a good choice, especially if you have a lot of conversions to make. However, you can also create your own converters that basically convert your domain model to your view model. In my case I created my own extension methods to convert my Comment domain model to my CommentViewModel like this:
public static class ViewModelConverters
{
public static CommentViewModel ToCommentViewModel(this Comment comment)
{
return new CommentViewModel()
{
Content = comment.Content,
DateCreated = comment.DateCreated.ToShortDateString()
};
}
public static IEnumerable<CommentViewModel> ToCommentViewModelList(this IEnumerable<Comment> comments)
{
List<CommentViewModel> commentModels = new List<CommentViewModel>(comments.Count());
foreach (var c in comments)
{
commentModels.Add(c.ToCommentViewModel());
}
return commentModels;
}
}
Basically what I do is perform a standard EF query to bring back a domain model and then use the extension methods to convert the results to a view model. For example, the following methods illustrate the usage:
public Comment GetComment(int commentId)
{
return CommentRepository.GetById(commentId);
}
public CommentViewModel GetCommentViewModel(int commentId)
{
return CommentRepository.GetById(commentId).ToCommentViewModel();
}
public IEnumerable<Comment> GetCommentsForPost(int postId)
{
return CommentRepository.GetCommentsForPost(postId);
}
public IEnumerable<CommentViewModel> GetCommentViewModelsForPost(int postId)
{
return CommentRepository.GetCommentsForPost(postId).ToCommentViewModelList();
}
Talking about Models, ViewModels and DTOs is confusing, personally I don't like to use these terms. I prefer to talk about Domain Entities, Domain Services, Operation Input/Result (aka DTOs). All of these types live in the Domain layer. Operations is the behavior of Entities and Services. Unless you are building a pure CRUD application the presentation layer only deals with Input/Result types, not Entities. You don't need additional ViewModel types, these are the ViewModels (in other words, the Model of the View). The View is there to translate the Operation Results to HTML, but the same Result could be serialized as XML or JSON. What you use as ViewModel is part of the domain, not the presentation layer.

How does ASP.NET MVC3 gather data from GET/POST into a model?

I've learned about custom editor templates for ASP.NET MVC3 and I see now how I can easily implement my own. However for an editor to work it must not only display that data in a textbox, but also somehow transfer the user-edited contents to the server for processing. So how does this binding work for complex models? How does MVC decide where each POST value goes? Are there some magic naming conventions? What about very complex models like dynamic lists or dictionaries or DataTables?
There is a naming convention. So for example if you have the following model:
public class Foo
{
public Bar Bar { get; set; }
}
public class Bar
{
public string Baz { get; set; }
}
and the following action:
public ActionResult Index(Foo foo) { ... }
you could send the following request:
/home/index?Bar.Baz=somevalue
in order to set the Baz value. Of course this will automatically instantiate the Foo model and its Bar property. And obviously this convention also extends for lists and dictionaries.
Whether the values are sent in the query string (GET request), as form values (POST request) or as route values it doesn't really matter for the default model binder. It will look at all those places.
And you should never forget that if this default naming convention doesn't suit your particular requirements you should feel free to write a custom model binder.
Remark: there is also the case for uploading files.

ASP.NET MVC 2 Using an interface to strongly type a partial

I'm experimenting with ASP.NET MVC2, in particular viewmodels and partials. My question is: Is it ‘valid’ or ‘right’ to have your partials strongly typed against an interface and the have your viewmodels implement that interface if the view uses the partial?
To illustrate, say I have a Product form partial (strongly typed against IProductFormViewModel) which is used in both the Edit and Create views. These views are strongly typed against ProductEditViewModel and ProductCreateViewModel which implement the IProductFormViewModel.
The benefit being that the corresponding POST actions for Create and Edit take ProductCreateViewModel & ProductEditViewModel objects respectively.
Edit:
If the partial has its own dedicated viewmodel (ProductFormViewModel) and each of the ProductEditViewModel & ProductCreateViewModel expose a property of type ProductFormViewModel which is passed to the partial, then when the form is submitted the model binding of ProductEditViewModel & ProductCreateViewModel doesn't work as the Edit and Create actions expect their respective object types...thats the reason for the approach.
You may have problems when your interfaces for your different partials expose the same property name e.g. name. You would then have to explicity implement the interface which would then cause problems with your model binding.
Otherwise it should work.
Yes, this seems a valid approach.
Interfaces are essentially contracts that need to be fulfilled by implementing classes. but in case of view engines i don't see any specific benefit of having you viewmodels implement an interface because at the end you have to instantiate the viewmodel in controller and pass it to the view and suppose you change implementation of ProductFormViewModel or EditProductViewModel, u still have to instantiate (populate) the object in controller and pass it to the view. so it does not achieve the same purpose as we do in repository pattern in conjunction with dependency injection. if you can tell what exactly u are trying to achieve by this approach, we might help.
Your approach is fine.
Or you could have a model specific to your partial and use composition instead, e.g.:
public class AddressModel
{
public string Address { get; set; }
public string Code { get; set; }
}
public class PersonModel
{
public string Name { get; set; }
public AddressModel Address { get; set; }
}
Then when redering your partial you pass it the correct model.
HTH

21 entities with the same structure. What I'm supposed to do when it's time to make a CRUD for these entities

I Have 21 entities with the same structure.
Same Attribute too.
Every entity contains these Attributes :
AreaType
ID
IsActive
LangID
TXT
ModuleType
ID
IsActive
LangID
TXT
...
What I Need to perform a generic Crud. I already know that I need to create a generic repository. My problem is to perform a kind of generic ViewModel.
How can I create a generic View for the Create Form.
I Dont know what I need to pass in the Inherits of the view to be Generic.
... Inherits="System.Web.Mvc.ViewPage<...Dont know>"
Any Idea ?
A common approach this problem is to use ViewModels. This is where you create specific classes to be used as the models in your strongly typed views. These classes would not be the ones created by EF. The ViewModel classes can have a common base that encapulate your common fields. In your data access layer you would need to move data between your ViewModel classes and your EF classes. Things like AutoMapper (from CodePlex) work really well to reduce, if not eliminate, all of the the tedious "left-hand right-hand" coding.
Not too familiar with MVC, but (assuming it fits in with your hierarchy), I think you could create an abstract class which contains the properties you need, e.g.
public abstract class ViewableObject {
public abstract int ID {get; set;}
public abstract bool IsActive {get; set;}
// etc
}
Then implement that with your normal classes (AreaType and so on), e.g:
public class AreaType: ViewableObject{
public override int ID { get; set; }
public override bool IsActive{ get; set; }
}
and make the view use the abstract class.
... Inherits="System.Web.Mvc.ViewPage<ViewableObject>"
One idea is to simply change your underlying tables. Combine AreaType and ModuleType into a single "WhateverType" table that contains a field identifying exactly what type it is. Then when you codegen your classes you'll have exactly one class to deal with.
However, there are other concerns and you should only do this if it makes sense in your application.

Resources