I'm new to MVC and I borrow a book from library yesterday on asp.net MVC 2.
I'm a bit confused about what kind of code should be included in Model, view and controller. I was working on user input validation from the book and if I understand correctly, it seems they declare variables in "Model", validating user input in "Controller" and display the web page in "View".
Model:
-Declaring variables
e.g:
class Contact:
public string Name { get; set; }
public string EmailAddress { get; set; }
Views:
-Contain HTML, HTML Helper code, displaying contents and use variables from "Model"
e.g:
<%: Html.TextBoxFor(model => model.Name) %>
<%: Html.ValidationMessageFor(model => model.Name) %>
Controller:
-"Playing"/"Manipulating" variables from Model + Call "View" to display web page at the end (return View()). (Validating user input for this example)
e.g:
if (String.IsNullOrEmpty(contact.Name))
ModelState.AddModelError("Name", "Please enter your name.");
I'm not sure but it seems to me that "Controller" is the "heavy coding" part to me. On the other hand, "View" is the good old HTML, markup that display the web site and "Model" is a place that store data (declaring variables for example.)
Please let me know whether I'm on the right direction.
Thanks :)
I'm not sure but it seems to me that "Controller" is the "heavy coding" part to me
You should avoid having fat controllers. In fact the controller might depend on a service layer which contains the business logic of you application. This service layer could itself depend on repositories performing the data access (simple CRUD operations) on the models. So the controller would simply invoke a business operation call on the service layer to fetch/update the model and then pass a view model to the view in order to display it.
I am also new to MVC and first thing i did when i started was to view most of the talks given by Scott Hanselman and Phill Haack. So you might try this one: [http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman][1]
[1]: http://channel9.msdn.com/blogs/matthijs/aspnet-mvc-2-basics-introduction-by-scott-hanselman to get started. From what i got so for, Darin is right. Try to avoid fat controllers and work with a repository for your model. Also, I noticed that for simple validation (required, maximum string length and such) it is preferred to use DataAnnotion on the model... So your Contact model might look like this:
class Contact:
[Required]
public string Name { get; set; }
public string EmailAddress { get; set; }
This will make the Name property required on Edit/Create Views.
Related
It seems weird that I couldn't find an explanation of the difference between those two helpers, so I would assume that is something obvious but I missed.
Basically I am trying to decide which one I should use for my case, with the following simple Model:
public class Booking
{
public int ID { get; set; }
public Room Room { get; set; }
public DateTime StartTime { get; set; }
public DateTime EndTime { get; set; }
public ICollection<Equipment> Equipments { get; set; }
public string Who { get; set; }
}
and I want display a simple Room DropDownlist for Adding and Editing Booking record.
After doing a lots of Google around, it seems that I probably need a DropDopwListFor, but not sure why and how?
Take the following two examples:
#Html.DropDownListFor(
x => x.EquipmentId,
new SelectList(Model.Equipments, "Id", "Text")
)
and:
#Html.DropDownList(
"EquipmentId",
new SelectList(Model.Equipments, "Id", "Text")
)
It is obvious that with the second example the name of the property you are binding the dropdown to is hardcoded as a magic string. This means that if you decide to refactor your model and rename this property Tooling support that you might be using has no way of detecting this change and automatically modifying the magic string you hardcoded in potentially many views. So you will have to manually search & replace everywhere this weakly typed helper is used.
With the first example on the other hand we are using a strongly typed lambda expression tied to the given model property so tools are able to automatically rename it everywhere it is used if you decide to refactor your code. Also if you decide to precompile your views you will get a compiler time error immediately pointing to the view that needs to be fixed. With the second example you (ideally) or users of your site (worst case scenario) will get a runtime error when they visit this particular view.
Strongly typed helpers were first introduced in ASP.NET MVC 2 and the last time I used a weakly typed helper was in an ASP.NET MVC 1 application long time ago.
DropDownListFor will automatically select the selected value by using the specified property:
// Will select the item in model.Equipments that matches Model.EquipmentId
#Html.DropdownListFor(m => m.EquipmentId, Model.Equipments);
Another comment:
Don't have ICollection<Equipment> Equipments in your view model. You should have a property that returns an IEnumerable<SelectListItem>.
When you want to add a view (aspx file) where this DropDownList or DropDownListFor will be inside, rightclick->add view then select "Create a strongly typed view" then in list select Booking class. After that add this page.
You can write in it as follows:
#Html.DropdownListFor(m => m.Equipments , Model.Equipments);
because we add strongly typed view as Booking, you can have:
m => m.ID, m => m.Room, m => m.StartTime
... etc.
In your services you can have methods to take data from database, then use this service's method in your controller to pass data from database to view. You can use ViewData in your controller:
ViewData["Equipments"] = new servicename().getdatalistfromdatabase().AsEnumarable();
Putting AsEnumarable() at the end of your list taken from database makes it IEnumarable.
Then in your view, you can also have :
#Html.DropdownList("MyEquipments" , ViewData["Equipments"]);
A link on ViewData usage:
http://msdn.microsoft.com/en-us/library/dd410596.aspx
I hope that helps you.
DropdownListFor is support strongly type and it name assign by lambda Expression so it shows compile time error if have any error.
DropdownList not support this.
I have an ASP.NET MVC3 application that uses entities generated from a database. Each entity has also has a separate partial class that uses the MetadataType attribute to associate each entity with a class that is decorated with a number of validation attributes (see below).
[MetadataType(typeof(Drawing.Metadata))]
public partial class Drawing
{
private sealed class Metadata
{
[Required]
[StringLength(50, MinimumLength = 3, ErrorMessage = "Drawing numbers must be between {2} and {1} characters in length.")]
[DisplayName("Drawing number")]
public string Number { get; set; }
[Required]
[StringLength(255, MinimumLength = 3, ErrorMessage = "Drawing titles must be between {2} and {1} characters in length.")]
public string Title { get; set; }
}
}
My controller code looks like this:
[HttpPost]
public ActionResult Create(Drawing drawing)
{
if (ModelState.IsValid)
{
// Save to database here...
return RedirectToAction("Index");
}
else
{
return View(drawing);
}
}
I have used the Visual Studio templates to create the views to add, edit and delete the entities (The designer code has not been altered).
The problem I am having is that when I create an entity, validation only works if I have client side validation enabled. If I turn off the client side validation then ModelState.IsValid always seems to return true and returns me to the index page.
Can anyone provide any suggestions on how to get server side validation working with Entity Framework entities?
UPDATE:
It seems this question is similar to mine. The author of this post seems to have solved the problem but rather unhelpfully omitted to mention how they fixed the problem...
I found another solution to this problem. Because I didn't really want to set my properties to nullable I added the following:
[DisplayFormat(ConvertEmptyStringToNull = false)]
Adding the following annotation to your model property fixes the error as well.
After further investigation it seems that my problem is occuring due to a ConstraintException being thrown by my entity class (which inherits from ObjectContext) when the default model binder tries to bind the user input values (Null in this case) to the entity properties.
I can see 2 possible solutions to this:
Relax the constraints on my database tables (I don't want to do this).
Make the entity fields nullable (use the entity designer set the nullable property to yes)
I have used and tested the second option and can confirm that server side validation now works as expected.
Whilst researching solutions to this problem I have come to the conclusion that the problem is due to my entities inheriting from ObjectContext which is quite a heavy class. I found a lot of tutorials which used a code-first approach. In this case, the entity class will inherit from DbContext which is much more lightweight so I guess this could be considered a third solution to the problem.
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.
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.
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