I have a model, called Organisation and the model is stored in an assembly called Model. There is a requirement to insert an organisation and update an organisation.
Couple of questions:
When inserting a new organisation, I want to ensure that the organisation doesn't already exist so I've inserted some remote validation. I then bind the model to the insert view.
Now, when I'm creating the update view should I use a different view model which removes the remote validation for duplicate organisation names? If so, I can't use my base Organisation model for the update view, so do I then need to create 2 different views, one for insert and one for update? If this is the case, there is going to be 2 views that are basically the same but just use different models.
Can anyone help?
For this specific scenario the validation that no other organization with the same name exists seems valid for both the insert and update case so you could reuse the same view model.
However validating that the name does not exists when updating a organization must have extra because if the user does not change the organization name then at least one record on the database has that name, the one being updated, and the validation should ignore that record.
So if you choose to reuse the view model the validation must perform according to the context of the operation (insert or update).
Question 1: check validation:
If their is something not valid, do this:
If(isNotValid()){
ModelState.AddModelError("Key", "The user name or password provided is incorrect.")
}
Key is the field in your view that is incorrect.
Question 2: Difference between Create / Edit
You should use the same ViewModel, because in your update, they can still change the "Organisation Name" and you should still check if it is unique.
But why should you use a ViewModel just to check the validation? Is there a reason why you can't check the organisation names for uniqueness in your controller and do a ModelState.AddModelError when it is not unique?
A ViewModel is when you have to extend the Page, For Example
public class DashBoardViewModel
{ public List(Of Organisation) Organisation {get;set;}
public List(Of Staff) Staff{get;set;}
public List(Of Assignment) Assignments{get;set;}
}
Above would be a fictional DashBoardViewModel where i show all the Organisations, Staff and Assignments.
A ViewModel doesn't contain just one type of object, it contains multiple.
And don't forget, sometimes when you need to add some data to a View, you could just use ViewData or ViewBag, instead of creating a ViewModel.
Related
I have a class Person. Which is associated with the Students. now students class contain a datefield "CreatedOn".
class Person
{
String Name;
List<Student> students;
-----rest of props and methods
}
class Student
{
DateTime CreatedOn;
DateTime UpdatedOn;
---------rest of props and methods
}
now my problem is I want to remove these dates (of student class) from modelstate while updating object of person class. How can I do that?
since a person can have 2 student and other can have any number of students.
if I need to remove "Name" from ModelState I would have used ModelState.Remove("Name") for person
but how can I do it for students of person. Is there something like ModelState.Remove("students") or
ModelState.Remove("students[0]") etc?
Please help me with example
I had answered similar question before here
For those who can't afford one extra click to visit the link
Ignore other properties(other than UserInfo) : ModelState.IsValidField(UserInfo)
Clear/Remove property error : ModelState["ExtraInfo"].Errors.Clear();
Create custom validator, as also suggested by ataravati : MVC Custom validation attribute
Option 1 and 2 will work only when client side validation is disabled.
Add two viewmodels one for update action and one for create action and exclude createdon and updatedon properties from the viewmodels,
This way you keep your controllers clean from additional complexity of clearing or adding errors and just test for ModelState.IsValid.
If valid then update or create the Student with updatedon or createdon respectivily.
After a year or so of MVC experience I'm still confused about one thing: How to effectively use the DataAnnotations with ModelState.IsValid? For simple tutorial example this all works just fine and I have no questions about that. But supposed I have the following model:
Public Class Movie
Public Property MovieID As Integer
Public Property Title As String
Public Property Year As Integer
Public Property AddedByUser As String
End Class
Now the field AddedByUser is required in the database however I don't want the user to provide this but rather the business logic based on the currently logged in user. How would I use the DataAnnotation attributes for this scenario? If I make this field required then in the controller when I say:
Public Function SaveMovie(ByVal entity as Movie) As ActionResult
If ModelState.IsValid
// Save to DB here...
End If
Return View(entity)
End Function
... the validation will fail because I don't have that field in the view bindings. Should I have a hidden field for this? Should I write a custom view model for SaveMovie action? I suppose I could write my own validation in business logic but then why use model validation at all? Custom model binder perhaps? What is the best way to handle these types of scenarios?
Just to give another example scenario what about the difference between insert and update operation and validation? For update operations object's primary key is required. However that is not the case for inserts. Are you supposed to have separate models for insert and update just because of this one key property?
so the way that I handle this is I use the DataAnnotation based validation for user input type stuff. i.e. Validation on email addresses, dates, required fields etc. Stuff that you need a quick 'sanity check' on and need to double check the users entries on.
I don't put any DataAnnotations on the fields that my Database controls or my code controls, i.e. Primary Keys, your [AddedByUser] property as the user doesn't access these properties directly and so you shouldn't have to add validation checks on this. Since your code is the only thing that updates these properties, why validate them?
For more 'business rule' type validation I implement IValidatableObject on my model which gets run, in MVC, after all property-level validations have succeeded. Note that it won't run if the property-level validations fail. And this makes sense, because if the data is 'dirty' you wouldn't want to proceed to run more complex validation etc.
Hope this helps :)
What's the best way to validate a model when using mvc with repository?
I look for examples but I didn't find any that is exactly what I need.
Assuming I have a model with 5 properties.. 3 of them with dataannotations.. and I have some validations that I need to check in database before insert.
I need something like 'User.IsValidToInsert' to check if its valid. But I want to use 'ModelState.IsValid' too, cause I dont want to check manually all properties with dataannotations in 'IsValidToInsert'.
How can I do this? Should I set validations that access database in 'IsValidToInsert'? Should I pass 'User' and 'ModelState' like parameters to repository class?
You should be using a View Model that is specific to the view. If you have a Create action to create a Product, create a ProductCreate view model. You can put the data annotations (or Fluent Validation, etc.) that is specific to creating a product. This will be the model for your View/Controller. If you have an Edit page, then create a ProductEdit view model.
Now if you have additional logic (such as validating if a user already exists, then you should put that in a service layer. Your controller should be as simple as possible. You post your view model, convert it to a domain model and pass it to the service layer if necessary.
[HttpPost]
public ActionResult Create(ProductCreate model)
{
// simple validations
if( !ModelState.IsValid )
{
return View(model);
}
// Domain Model / Entity
Product product = // create a product from your model here
// service layer
ProductService.Add(product);
return RedirectToAction("Index");
}
I have a class set up to hold values on a registration form (VB.NET, MVC), and among the properties is a Password property:
Public Class RegisterModel
...
Private _password As String
<DisplayName("Password:"), Required(), ValidatePasswordLength(), DataType(DataType.Password)> _
Public Property Password() As String
Get
Return _password
End Get
Set(ByVal value As String)
_password = value
End Set
End Property
This works great when registering a new user, but I'd like to use the same class to update existing users. (Note: this app is run by an admin who is in charge of registering individuals and assigning passwords.) The way I'd like it to behave is if the admin leaves the password blank, then the password is not changed, but the rest of the information is. If I use this class, the password can't be left blank because it fails on the Required() and ValidatePasswordLength() calls.
Is there a way to use this class but tell the model to ignore these particular validations? Even if I leave the password field off my edit form, it still fails. Do I need to create a whole duplicate class without these restrictions on the password field? There must be a better way.
You could implement IDataErrorInfo and have a flag set on the model which indicates whether it is being used by an admin or not - you could then validate conditionally.
But overall, I'd say this is a bit of a code smell. You're using a model for two different, incompatible purposes. It'd be better to use a separate view model.
I'd recommend using the FluentValidation library. It's a fantastic way to separate the concerns of your view (view model) and the actual validation you want to perform. You could pass parameters into it to drive different behavior. Check out When/Unless conditions or just writing completely custom validation methods with the Must operator.
public class RegisterModelValidator: AbstractValidator<RegisterModel>
{
public RegisterModelValidator(bool isAdmin)
{
RuleFor(x => x.Password).NotEmpty().Unless(isAdmin);
...
}
}
As long as your view model would have identical properties in both scenarios, you should use the one view model and one validation class. If the model varies at all I'd use two view models as David recommends.
You can do this in 2 ways:
1: add the [ValidateInput(false )] attribute to the action
or
2: Add a new property to the Register Model
public bool IsNewUser {get;}
3: Create a new class level attribute that takes IsNewUser into account when validating
Here is the lay of the land. Like most people I have my domain object and I have my view models. I love the idea of using view models, as it allows for models to be created specifically for a given view context, without needing to alter my business objects.
The problem I have is with type level validation defined on my domain object and getting those rules to the client. In this case lets say I am using data annotations to describe the validation rules, when I move the data from the domain object to the view model, the view model no longer knows what validation it should get the interface to perform (because the validation is defined back on the domain object).
With MVC 2 you can get it to automatically perform client/server side validation, based on the validation rules of the current object. But because the validation rules are defined on the domain object and not the view model, I would have to duplicate the validation rules on the view model to get this to work.
How do others deal with this type of issue? My thinking is that besides mapping the data from the domain object to the view model, we also need to map across the validation rules, but I haven't really seen others talking about this issue... Brad Wilson has recently talked about this issue at length but hasn't really addressed the duplication of rules on the domain object and on the view models... what are your thoughts?
Cheers
Anthony
The DataAnnotation attributes are about validating input and giving UI feedback to the end user. That's really their only intended use. I use different validation strategies for UI objects and business objects, so the DA validation attributes only end up on models being shown to the user.
This may not be appropriate, but what if you just moved your validation rules/annotations from your Models to your ViewModels? In a few of the projects I've been on, we've chosen to prevent the View from accessing anything but information exposed through its corresponding ViewModel. Since all data interaction would be performed through the ViewModel, there wouldn't be a need to have validation on your Model objects.
The counter to this argument is that you could easily duplicate certain validation rules, since different ViewModels might be interfacing with the same Models. In this case, it might make sense to simply declare your Model as a property exposed on your ViewModel. For postbacks, they could accept a Model as their parameter, allowing the ModelBinder infrastructure to handle the request. In this case, if ModelState.IsValid is false, you could just reassign the property to your ViewModel before redisplaying the View.
I would recommend moving your annotations to your ViewModels. It makes sense since a lot of Views are a) the result of composition of several models or b) a subset of model data.
It turns out that AutoMapper may be able to do this for us automagically, which is the best case scenario.
AutoMapper-users: Transfer validation attributes to the viewmodel?
http://groups.google.com/group/automapper-users/browse_thread/thread/efa1d551e498311c/db4e7f6c93a77302?lnk=gst&q=validation#db4e7f6c93a77302
I haven't got around to trying out the proposed solutions there, but intend to shortly.
(Cross posted this on my (dupe) question as well).
Probably we shouldn't use view models at all?
And define validation rules on model layer entities..
I've been considering this as well for a while now. I totally understand Brad's reply. However, let's assume I want to use another validation framework that is suitable for annotating both domain entities and view models.
The only solution I can come up with on paper that still works with attributes would be to create another attribute that "points" to a domain entity's property that you are mirroring in your view model. Here's an example:
// In UI as a view model.
public class UserRegistration {
[ValidationDependency<Person>(x => x.FirstName)]
public string FirstName { get; set; }
[ValidationDependency<Person>(x => x.LastName)]
public string LastName { get; set; }
[ValidationDependency<Membership>(x => x.Username)]
public string Username { get; set; }
[ValidationDependency<Membership>(x => x.Password)]
public string Password { get; set; }
}
A framework like xVal could possibly be extended to handle this new attribute and run the validation attributes on the dependency class' property, but with your view model's property value. I just haven't had time to flesh this out more.
Any thoughts?