I have used yii framework in php extensively and find scenarios very useful.
to summarize, scenarios let you have different validation criteria for different views.
Question
Can I use mvc3 built in validation and yet have different validation criteria for different views .Is there a built in function for this?
Explanation
In one of the forms I only want to validate change of password, in another form I just want to validate new user parameters, yet another place only requires validation of some detailed data input. All values are stored in the same table but need different input value sets
No, because the built in framework validation is attribute based, it makes it difficult to change validation requirements at run time if you're sharing models across views.
As such, your best bet would be to create different models for each view.
If you need to have custom validation applied at run time to your models then you can use http://fluentvalidation.codeplex.com/
It's not built in, but works with the existing ASP.NET MVC validation components and as such can be used with unobtrusive validation / model state etc.
Related
So I've found similar questions, but could really use some help! I have an Entity Framework Application with a whole bunch of tables. I've had to add a new table, and I understand that I can get the model to update using the wizard from .edmx file. The problem is that I REALLY don't want to udpate all of the other models. I've added validation for my models as they're being used in forms, regenerating these models will get rid of all that code. Any suggestions? Thanks a lot.
You won't be able to preserve the changes you made to the auto-generated classes as part of the .edmx.
This may not be the answer you want to hear, but your situation is one of many reasons to use different classes for your user submitted data (i.e. web form in your case).
A few other reasons you should separate your models:
Prevent over-posting which could result in bad data or even security issues
Keep your data models clean and simple by avoiding having UI specific properties (e.g. SelectList which is an object to help populate <select> elements, but doesn't need to be part of the database)
I've noticed in ASP.NET MVC, it's commonplace to use model binding and validation annotations in conjunction with business objects that also interact with the database.
Unfortunately, this means that the scope of the request and the validation taking place must always be 1:1 with domain models. At the very least not without having to code a bunch of exceptions.
If I'm looking for a way to do contextual validation in ASP.NET MVC, are there any examples of or is it an accepted practice already to use POCO classes that represent the incoming data?
Let's say I call these "Request Models". An example might be that I create a class called UpdateUserRequestModel. I define only the data that I allow for a user update, then, I have MVC bind the values into this surrogate model. Later in my controller/services, I access the request model's public properties for the values I wish to move over to the user object.
So, the question here is: Is there already any example of this practice in commonly accepted ASP.NET MVC conventions? Does it have a particular name? Failing that, when I wish to do contextual validation, are there any better options than the default model binders and value providers that MVC ships with?
I do it on my apps. I validate actions the user performs, putting validation attributes etc on that view model that represents that action (conveniently models the form in the view and model binds the result on the way back). I even ported the ContosoUniversity app to reflect this style:
https://github.com/jbogard/ContosoUniversity
Is it possible to call multiple stored procedures (not multiple result sets from a procedure) and display results on a single page in ASP.NET MVC 3 application?
From what I understand only one Model can created on any single page and my stored procedure is already tied to that Model. I would like to call another procedure and display that result as well on my page
I think the root problem is to understand the meaning of the Model in the MVC pattern.
First of all,
The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3] A view can be any output representation of data, such as a chart or a diagram
source
In ASP.Net MVC you link a model to your view, this model should not be part of your domain logic or any domain object
The real model (using the meaning of the MVC pattern) is represented by your domain objects.
So what should you put inside the object that you link to your view??
These objects should contain a representation of the view, in other words simple DTO's containing only the data that is going to be used in the view and nothing more. These models should represent the data being used in the view. If you follow this approach, and you need to display more data in the page, you only need to add another property to this model and voila, you can use it from your view.
In a CQRS architecture, these DTO's should be populated by the Query repositories.
If you do not have a CQRS architecture, just populate these objects in your domain, repositories, etc. Do not do it inside the controller, keep your controllers clean and simple, by making calls to your real domain using services or repositories
Try to avoid the reuse of these DTO's, they should belong to one view only. And do yourself a favor and do not try to reuse a domain object instead of a DTO just to use it as the model.
Following this approach your view-models will be clean, since they will be only DTO's and only containing the data needed by the view. And you can fill these DTO's from different sources, even from different databases if you want.
When you want to perform an action you would read from the model the data provided by the user, and with this data you would call your domain through repositories, services or in a CQRS arc. using commands
The simple answer to your question is "yes".
I suggest you do some more research (ie reading articles and looking at sample apps) into MVC and concentrate on understanding these points:
The Model is a class used to group the data you want to display in the View. It can be populated by a variety of methods and does not have to be the domain object or the pure representation of the database result.
A "page" (the concept of what a user sees in their browser window) can be made up from one or more Views. Each View can be responsible for displaying one type of Model allowing for reuse, but a "page" can have multiple Views.
Models are not "tied" to stored procedures. Perhaps you are using an ORM tool that returns a DTO class (which you call model)? This doesn't have to be the Model used by the View. The Controller could compose several of these DTO classes into one Model class.
N-tier application design where database access is separated from the display logic. MVC tries to encourage this but it still has to be done correctly to avoid tying yourself in knots.
Good luck!
In a wpf application using POCO classes with Entity framework, what is the best way to perform validation on data. I am aware of data annotations but if I am not compeltely wrong they are more used with ASP.Net MVC than WPF (i didnt find many examples with WPF). Earlier I was having my Domain classes implement the IDataErrorInfo interface but I wasnt sure if this was the correct approach. If I would want to share my EntityFramework classes at a later stage with say a silverlight application or an ASP.NET application what would be my best approach so that I can reuse my validation rules. (With ASP.net i believe my IDataErrorInfo way of handling errors would be useless?).I can find a lot of similar questions but not one that particularly meets my needs. It would be great if anyone can point me in the right direction
I have been using T4 templates on my domain model to generate the POCO classes and have been using these POCO class objects as business objects too
Out of the box, WPF Validation uses IDataErrorInfo and/or ValidationRule's on bindings. IDataErrorInfo being the partial classes that provide a way to tie in additional logic to make sure the value is valid (IE: The Person.Age property is between 1-100) and ValidationRule's being able to inspect the value before it is ever applied to the binding (IE: The Person.Age property is an integer at all). IDataErrorInfo is obviously only helpful when the value of a Binding gets updated with a compatible datatype, ValidationRule's are helpful in the event somebody types "Ten" instead of 10, in your Age textbox and the datatypes are not compatible.
IDataErrorInfo is reusable for all WPF/Silverlight/ASP.NET projects, (see: How to use IDataErrorInfo in ASP.NET)
Whereas ValidationRule's are to be used with Bindings and therefore not useful in a ASP.NET project. They could be considered the equivalent of Javascript validation.
In short, IDataErrorInfo is exactly what you're looking for and will provide the most reuse for those technologies.
IDataErrorInfo is not supported out-of-the box with EF validation. Annotations are used not only for validation but also can be used to define your model (e.g. Required, MaxLenght, StringLength attributes etc.). Out-of-the box you can use a few more mechanisms to validate your entities - by writing your own attribute by deriving from ValidationAttribute, by using CustomValidationAttribute or by implementing IValidatableObject. That's what EF supports out of the box. If neither of these works for you can replace built-in validation by overwriting DbContext.ValidateEntity() method and use any validation mechanism that works for you. A couple useful links: http://blogs.msdn.com/b/adonet/archive/2010/12/15/ef-feature-ctp5-validation.aspx
http://blogs.msdn.com/b/adonet/archive/2011/05/27/ef-4-1-validation.aspx
In reading up on ASP.NET MVC I came across some wonderful examples of validation where the business rules were associated with the model and the UI merely displayed the set of errors and flagged the form elements associated with invalid input. I think it makes fantastic sense to keep this logic in a single place rather than have every form perform its own unique validation.
Is it possible to achieve this separation in an elegant manner with an ASP.NET Web Application project (webforms)? I can keep the validation rules in the business logic layer and I can have methods that perform validation and return a set of errors. But I can't figure out a good way to flag problematic controls on the UI side.
In MVC the form elements and model are implicitly linked by property names. Should the UI in ASP.NET reference the unique property names of the model (either as ID/name or as a custom attribute)? Should the UI have access to a manually-generated mapping of control names to property names?
A way I like to do it is to create CustomValidators, bound to control on the screen and I call my BL validations in the OnServerValidate event. That way, my validation logic stay in one place.
Hope it will help
I'm sure I remember hearing some where that some improvements around Data Annotations would be available for WebForms in .NET 4.0, but after trying to search for it online I'm starting to think I dreamt it.
Although I did find this post of a guy that 'rolled his own':
http://adventuresdotnet.blogspot.com/2009/08/aspnet-webforms-validation-with-data.html