We say that model validation at controllers layer is the correct place to validate all data we gonna operate with. In this case, if we change UI to another (remembering that our layers must be pretty decoupled) the new data validation principles are going to execute - in this case all our inner rules can be violated.
You may say that data models is the separate layer and that layer, but not UI, is the only place for validation. But in this case i found it more effective to validate data in the service or business objects layer, don't i?
In fact we have a number of objects corresponding to our domain object: db table record, linq2sql class, domain object class, viewmodel class. Should it be only one place to validate data model? Why should it be in (or close to) UI but not in the other layer? In my opinion, the validation must occur in the service layer - with all other busness logic. If i need to inform user about error as fast as possible, i'll use client validation in addition to main one. Thoughts? Thank you.
Data validation is the responsibility of the model. The best place to put validation rules in my opinion is as constraints in the database. Having constraints ensures that no incorrect data will ever be stored in the database, no matter how it is access. Unfortunately only basic constraints are suitable to express in the database.
The next place to put validation, when using linq-to-sql for data access, I is the extension methods on the entity classes. Then all code will have to pass through the validation.
To improve user experience, basic validation can be repeated in the UI, but that is just for user experience and to catch the most common mistakes early. On the web, using JavaScript validation is preferable. On rich clients the same code as the one called by the extension methods can sometimes be reused.
Always remember that any service exposed to a client, could be called by a malicious client that lacks the validation that the real client does. Never trust the client to do any kind of validation or security checks correctly.
1.It is validated at UI level because to reduce the one extra hit to server. (EnableClientSideValidation check). And its for basic validations only(like invalid input etc)
2.Many business validations are written in Business layer where they intact irrespective to the UI(WPF or MVC)
3.Usually we write UI validation in controller and specific to MVC.
4.You should keep the validation part as per the prefrences. like sometime we validate entity for unique constraint in such case I would prefer to write my validation attribute over the Entity itself.So at the time of insertion to the database it will be validated.
Also you can try to introduce another layer(new library) here for simplicity and decoupling approach,
This new layer will do, some validation which are not specific to UI and not specific to business logic. We will call it as App Services Layer which also actually helps you to interact with WCF like scenarios. So now your controller and WCF will interact with same layer and with same validation.
Data Validation should happen at the domain level. But UI validation errors should be caught without having to ask someone else downstream.
Related
It is common sense to keep business logic out of controllers. It is also common sense that database access logic should be on a repository, using a repository pattern, as described here: Repository Pattern
However, the repository pattern specifies only very simple low level database operations: Insert, Delete, Update, Select. People advise to keep validation logic out of it too. That is not a problem, since most of the validation can be put inside the model object itself. The problem comes when we need to make some kind of cross-validation, that is, a validation that needs to look on more than one instance of the same model object (for example, ensuring that a name is unique accross all instances of same object) or, even worse, when the validation logic needs to check two or more objects of different types. In this case, we have a real big hole: the business logic cannot be in controller, cannot be in the repository, cannot be in the object model itself (since the logic is not bound only to the object's properties). Where should this logic be? What is the best design pattern for this kind of requirement?
You can create a service layer as described here:
http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validating-with-a-service-layer-cs
The problem here is that your design requires the UI to do validation based on business concerns.
The way to accomplish this is to abstract the validation into the business layer. Your business layer may have methods like ValidateUserIsUnique() and then your ui calls into this layer and receives a result, which is then used for validation.
In particular, for client-side validation MVC provides the RemoteValidationAttribute, but this will only do client-side validation. You will also need to do a server-side validation that calls the same (or a similar) function on the server.
A typical EF+MVC system will have two or three levels of validation:
For ViewModel: input / physical validation (DataAnnotations, FluentValidation), in other words, length, null, range, regex, etc.
For Model: input / physical validation (repeat of 1 in case MVC is not used and data comes from another system, WCF, forms, etc.)
For Model: logical / "business rules" validation
I can't find best practices for validation of 2+3 for the actual Model / entities / domain / "business rules". We either:
put simple validation rules in an entity's property setter (but this is really messy)
hook into EF's SaveChanges(), and if an entity is in the Added or Modified state then trigger validation (which validates the entire entity at once)
This is hard to maintain. A lot of thought went into ViewModel validation, but for Model validation it is domain-specific and so it is for you to determine a creative solution, and mine is not that great.
Are there better ways to do this, or helpful tools (like maybe DataAnnotations or FluentValidation but for domain entities)?
Where is the best place to do model validation or to trigger the model's validation?
A typical MVC+EF system will have 3 layers, but they aren't what you're talking about.
Presentation Layer (input/output)
Business Layer (Logical layer)
Data Layer (model represents low-level data)
MVC provides validation for layer 1. EF provides validation for layer 3. There is no validation functionality provided by either MVC or EF for layer 2. If you want validation there, you have to do it yourself, or use a third party business object framework.
Validation in layers 1 and 3 are separate, even though in many cases they may have similar validation. The reason is that validation is accomplished in different ways, and with different requirements.
For example, you may have a field in your database that is nullable for data modeling or business logic reasons (let's say some data is pre-loaded and the user is required to update the field as part of the business process). The data layer says it's nullable, but you want your UI to make it required.
EDIT:
Simply put, the Data model should not be enforcing business rules. Therefore, you should not need any validation in the data model, other than to validate against the physical data model (ie, if the field is nullable, the data type in the model should nullable, otherwise not). In most cases, you physically cannot insert invalid (from the data models perspective) data because the code model will not allow it. The only exception to this is string variables, which can obviously overflow the size constraints of the physical model, but if that happens then an exception gets thrown anyways.
Your middle tier, the business layer, should be where you need to validate business rules (for example, that a customer purchase order must start with a letter). Neither MVC or Entity Framework, or WCF or whatever provide any way to do this validation.
There is a bit of a disconnect here, because the business rules should (in theory) drive the presentation layer validation. But, MVC has no built-in functionality to do that, though. So you end up duplicating your business rules in the UI.
There is at least one third party business object framework that tries to deal with this. CSLA. They provide a custom MVC model binder that ties in the business objects with the UI to do validation, but this is just using the built-in extendibility of MVC to do this.
So, if you don't want to use a dedicated business object framework, you are stuck either duplicating validation between UI and Business layer, or trying to figure out your own way to make your own business layer control UI validation.
In a typical MVC application we have validation that occurs in many different places. It might be client-side, in the controller, and then again at the data level. If you have a business layer, then there is additional validation there as well.
How do we unify all these so that we're not violating DRY, and causing support nightmares when validations change? A sub-question is how to enable dynamic validation based on the model across all layers.
For example: We may have a ViewModel that has data annotation attributes. In MVC2/3 this unifies client-side and controller validation, but does not help with the data model (unless you are using your data model as your view model, which isn't a good practice).
This means you have to add the same validations to the data model and business layers, duplicating it. What's more, the data model might have subtly different validation requirements than the view model (for instance, an entire data record might comprise several view models of a multi-step wizard. And only a complete record can be saved).
Some people add complex validation to the data model when using an ORM like EF or L2S with partial classes, which i'm not sure is the right path either. It works for apps that are primarily data oriented (data entry type apps), but would not work for apps that have more non-data business logic.
What I'd like is some way to either generate validation for all layers, or a way to hook into a single validation system. Does anything like that exist?
"Fluent Validation" provides better re-usability.
Please visit.
http://fluentvalidation.codeplex.com/
Re-usable documents for Fluent Validation.
http://fluentvalidation.codeplex.com/wikipage?title=CreatingAValidator&referringTitle=Documentation&ANCHOR#ReusingValidators
http://fluentvalidation.codeplex.com/wikipage?title=CreatingAValidator&referringTitle=Documentation&ANCHOR#Collections
Below one may be full fill your needs.
http://tnvalidate.codeplex.com/
I guess I really don't understand your answer since rarely is your data model, business model, and view model all the same. If they are, just use the data model and put the validation on it. The validations across all your layers are specific to the layer.
Example: Your ui should not contain business layer logic in case you ever change the ui layer, or create a new one.
I'm not interested in answers concerning client side validation or model binding. Really, this question could apply to any data access class library outside of MVC, but the issues are similar, I think.
I'm using the Repository pattern currently for data access with my entities (models). Currently the repositories handle all of the CRUD operations, but I think I'd like for my models to be responsible for saving themselves in order to do validation. How should I handle this?
I could add a IsValid method in my models that the repositories could call that could then run all of my business logic before the repository saves the model, but then nothing FORCES the repositories to call this validation logic, right?
If I want the models to have a Save method, then what's the proper way for them to save themselves? They shouldn't call back up to the Repository should they?
Any thoughts on how I should handle this?
Thanks!
There's nothing inherently wrong with allowing the model to validate save operations; it is even feasible to return false or throw an exception. The difficulty arises when you must then provide feedback to the user as to why their entered data is not valid.
Validation can and should occur in the view first. This can readily be done client-side using jQuery libraries. But the data must still be validated server-side after the user submits, and if there are still problems with the data, you must still provide an explanation to the user.
Because of the need to provide user feedback, server-side validation of this sort can be effectively provided in a View Model object. This data object serves two purposes: first, it encapsulates the data that passes between the view and the controller in a strongly-typed object. Second, it provides a convenient place to perform validation, without requiring validation logic in either the controller or the view.
If Linq to SQL is used, the View Model can be an extension of the actual data model class, using the partial keyword in C#. This allows you to use the existing ORM capabilities of the generated Linq to SQL class, while tacking on the additional validation functionality. I assume that this works the same way in the Entity Framework, and other ORMs.
View Models are described in the NerdDinner tutorial here:
http://nerddinnerbook.s3.amazonaws.com/Part6.htm
The validation process is described here:
http://nerddinnerbook.s3.amazonaws.com/Part3.htm
Where do you put user input validation in a web form application?
View: JavaScript client side
Controller: Server side language (C#...)
Model: Database (stored procedures or dependencies)
I think there is validation required by each level:
Did the user input a sane value
are dates actual dates, are numbers actualy numbers ...
Do all of the checks in 1. again plus checks for malicious attacks(IE XSS or SQL injection)
The checks done in 1. are mainly to avoid a server round trip when the user makes a mistake.
Since they are done on the client side in javascript, you can't trust that they were run. Validating these values again will stop some malicious attacks.
Are dependencies met (ie. did the user add a comment to a valid question)
A good interface makes these very hard to violate. If something is caught here, something went very wrong.
[inspired by this response]
I check in all tiers, but I'd like to note a validation trick that I use.
I validate in the database layer, proper constraints on your model will provide automatic data integrity validation.
This is an art that seems to be lost on most web programmers.
Validation in the model, optionally automated routines in the UI that take their hints from the model and improve the user experience.
By automated routines I mean that there shouldn't be any per-model validation code in the user interface. If you have a library of validation methods, such as RoR's (which has methods like validates_presence_of :username) the controller or view should be able to read these and apply equivalent javascript (or whatever is convenient) methods.
That means you will have to duplicate the complete validation library in the ui, or at least provide a mapping if you use a preexisting one. But once that's done you won't have to write any validation logic outside the model.
Validation can be done at all layers.
Validating the input from a web form (all strings, casting to proper types, etc) is different from validating the input from a webservice, or XML file, etc. Each has its own special cases. You can create a Validator helper class of course, thus externalising the Validation and allowing it to be shared by views.
Then you have the DAO layer validation - is there enough data in the model to persist (to meet not null constraints, etc) and so on. You can even have check constraints in the database (is status in ('N', 'A', 'S', 'D') etc).
This is interesting. For the longest time I performed all validation in the model, right above what I would consider DAL (data access layer). My models are typically pattern'ed after table data gateway with a DAL providing the abstraction and low level API.
In side the TDG I would implement the business logic and validations, such as:
Is username empty
Is username > 30 characters
If record doesn't exist, return error
As my application grew in complexity I began to realize that much of the validation could be done on the client side, using JavaScript. So I refactored most of the validation logic into JS and cleanuped up my models.
Then I realized that server side validation (not filtering/escaping -- which I consider different) should probalby be done in the server as well and only client side as icing on the cake.
So back the validation logic went, when I realized again, that there was probably a distinct difference between INPUT validation/assertion and business rules/logic.
Basically if it can be done in the client side of the application (using JS) I consider this to be INPUT validation...if it MUST be done by the model (does this record already exist, etc?) then I would consider that business logic. Whats confusing is they both protecte the integrity of the data model.
If you dont' validate the length of a username then whats to stop people from creating a single character username?
I still have not entirely decided where to put that logic next, I think it really depends on what you favour more, thin controllers, heavy models, or visa-versa...
Controllers in my case tend to be far more application centric, whereas models if crafted carefully I can often reuse in "other" projects not just internally, so I prefer keeping models light weight and controllers on the heavier side.
What forces drive you in either direction are really personal opinion, requirements, experiences, etc...
Interesting subject :)
Validation must be done in the controller - it's the only place which assures safety and response.
Validation should be done in the view - it's the point of contact and will provide the best UE and save your server extra work.
Validation will be done on the model - but only for a certain core level of checks. Databases should always reflect appropriate constraints, but it's inefficient to let this stand for real validation, nor is it always possible for a database to determine valid input with simple constraints.
All validation should happen at least one time, and this should be in the middle tier, whether it be in your value objects (in the DDD sense, not to be confused with DTO's), or through the business object of the entity itself. Client side validation can occur to enhance user experience. I tend to not do client side validation, because I can just expose all of the things that are wrong on the form at once, but that's just my personal preference The database validation can occur to insure data integrity in case you screwed up the logic in the middle tier or back ended something.
I only do it in the View and Controller, the database enforces some of that by your data types and whatnot, but I'd rather it not get that far without me catching an error.
You pretty much answered your own question though, the important thing to know is that you can never trust the view, although that's the easiest route to give feedback to the user, so you need to sanitize on at least one more level.
Hmmmm, not sure. I would have said the Controller until I read this article re: skinny Controllers, fat Models
http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
Since most of validations depends on business rules, I do the validation on the business layer as third party tool classes. There are other types of validations, such as user input, whereas it needs to be made in the controller, but you can encapsulate those validation rules in third party classes too. Really, it depends on what to validate.
The client side validations are the minor ones, just made to build a lightweight input validation, but the server side validation is required always. You never can trust in the user input ;)
.NET have nice controls to build validations, but the business layer always needs a better approach to validate the data and those controls are not enough to that task.
Simple input validation in the view. Full validation in the model. Reason? If you change your view technology, and the validation is in the view/controller, you have to rewrite your validation for the new view. This can introduce bugs. Put it in the model, and this is reused by all views...
But, as I said, simple validation in the view for speed and ease.