My current requirements are overriding validation at runtime when validating a models state after posting a form.
I have a working solution of using normal Data Annotations for model state validation, that's standard in the world of .net, but what I would like to do is, override that validation at runtime.
I know is possible using Microsoft.Practices.EnterpriseLibrary, here is an example of an stack exchange question on the topic, Runtime Model Validation, ideally I'd like the kind of behavior to change model validation at runtime, instead of Re-deploying the solution and doing the necessary changes on the model class.
Ideally I'd like this kind of behavior without having to use Microsoft.Practices.EnterpriseLibrary since its been deprecated a couple years back.
The test program I'm currently working in is a .net 6 controller/view project.
Any suggestions relating to .net 6 would be helpful, I've looked in fluentValidation for this, currently not a support feature atm.
Thanks guys.
Related
I have just started to look at Azure Functions and one of my biggest concerns currently is validation.
I have only really looked at the CRUD operations so far, but there doesn't look like a way to easily validate data coming from the request or into the storage.
I have found this poco-validation and thought it might be useful.
I know this is kind of and open ended question but I'd be interested to see what others was doing for validation.
We recently added Function Filters to the underlying WebJobs SDK but that feature isn't fully exposed yet in Azure Functions (see issue here). Related to this, we're also considering support for validation annotations to be applied to your POCO types (issue here).
Until the above issues are addressed, we realize the story for validation isn't great. The recommended approach is to perform required validation in your function code calling out to shared validation helpers/code as needed.
Right now the application being built by our team uses the built in MVC attributes and a few home baked ones to validate the View Models. Because of best practice design principles, we have placed those same rules in the Logical Layer. This has unfortunately caused duplication of validation code.
In MVC3 at least, if JavaScript is disabled, these same attributes will still perform the validation they are meant to, so transforming a View Model in to a DTO and asking the Logical Layer to validate it is not an option because this process would have already been done by the framework.
I have not found the following SO post to be of any help. I have used MS Enterprise Library and the API did not sit well with our team.
Good practices for avoiding validation logic duplication when working with both domain objects and view models in ASP.NET MVC
I'm thinking that the best way to do this is to have the validation attributes bound at runtime to specific properties and have a dependency injection container do this. Is this possible or is there a different approach we could take?
You are asking for multiple validation types to be performed here.
You want client validation (it seems) and some other business validation layer.
If thats the case the only choices as I see it are:
duplicate the code (ya I know Im listing options)
1a. use data annotations on your objects for client validation. Business layer validation happens however you define, and separate as a final check. If you use for instance the entity framework's fluent API this is a standard route.
client side validation is just that - helpers for client side. domain validation will happen upon save. This is ideally the more powerful approach, but isn't as friendly when your domain objects don't match property names on your view models, so you need to map domain errors to view model property errors which normally isnt too bad but can get iffy.
implement IValidteableObject (and rid of client validation). This validation logic is then called from your logical layer and the model binder.
You can inject code for validation, but its not pretty and Im not sure how reusable it is outside the MVC validation route.
There may be other ways beyond this, but those are the main options as I see it.
One way of seeing it is: If your api is your mvc application and the validation is already done by the point you are executing your business rules, you can just assume they are valid. It's input validation, of course is something related to your domain but... if you change the way of thinking, your domain expects valid data and assumes you did your homework before using the business rules.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I realise this might be a little vague but I honestly don't know where else to ask. I have some history with PHP and I am trying to teach myself ASP.NET MVC3.
While I can find a LOT of source material on syntax and tutorials on various parts. I've started it off and I've got quite a bit going but I'm finding it a bit difficult to figure out exactly how to design the whole thing with regards to where to put things and I'm not entirely certain who I can ask or where I can find these things out?
The project I'm working on, in an attempt to teach myself is a form of online rpg game site. I've got user registration and log in, I wrote a custom membership provider to fit that to my existing database structure. But the trouble I'm having knowing where to do database lookups and how to store data etc. For example, let's say you log in, you have a certain amount of gold. On the right side of the status bar on the _layout page it will always display this value. Where do you look this up? How do you remember it? In the controller? Which controller? Etc etc.
Can anyone maybe recommend either a good set of advanced tutorials or some kind of forum where this can be discussed?
Thanks!
I learned everything i know from:
Getting Started with ASP.NET MVC 3
ScottGu's Blog -> awesome blog entries on mvc 3
Must see the Music Store Tutorial App
Check out a great book by Steve Sanderson - Ive used the previous two editions to get me upto speed with MVC.
Pro ASP.NET MVC 3
If your looking to use Entity Framework then I can also recommend;
Programming Entity Framework
The MSDN and ASP.NET sites have a LOT to offer on MVC3. I would also suggest buying the two MVC3 books by Phil Haack and Steve Sanderson.
http://www.asp.net/mvc/tutorials/getting-started-with-aspnet-mvc3
http://www.asp.net/mvc/tutorials/overview/creating-a-mvc-3-application-with-razor-and-unobtrusive-javascript
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
http://msdn.microsoft.com/en-us/library/gg416514%28v=vs.98%29.aspx
http://weblogs.asp.net/jgalloway/archive/2011/03/17/asp-net-mvc-3-roundup-of-tutorials-videos-labs-and-other-assorted-training-materials.aspx
Those are all good links and tutorials. In addition, you are going to want to have a separate database for your data vs. your Authentication and Authorization. This will allow decoupling and better security. You should be storing data in a database, and then the model will hold access to that database through a DAL (Data Access Layer) usually with the controller holding an instantiated repository of the DAL. In this sense the controller can build objects from the model (and thereby from the database) and then send them to the view through strongly typed objects for you to use in a User Interface.
Nerd Dinner is a pretty good sample of the whole picture, you can download the sample code and play with it.
http://nerddinner.codeplex.com/
The problem I find is a lot of examples don't use best practices for MVC in favour of simplicity and ease of reading in tutorials. So I'll outline some of the things I've found out the hard way and that work for me.
Personally from what I've found is your controller should be responsible for handling information via ViewModels to act as Data Transfer Objects (DTOs) between your business logic and your views, and that's all they should have in them. I choose to never have business logic in the controller and instead opt for a series of service classes designed to deal with their own group of responsibilities (IoC takes care of most concerns the Services may have).
This is done to keep the business logic DRY and to make it easier should you decide to try making a mobile version of your site later, or maybe expose a public WebService/API to your data.
The views should each use ViewModels specifically meant for each view, and these views should ONLY consist of primitive types or other view models. Never use a data entity from your ORM directly, though I'll be honest I have been known to break my own rule on this when it comes to views that only display information, but I usually pay for it later. Validation rules imposed on your data model are not necessarily applicable to a form and data loaded on your entity may not be relevant to your view either. ORM's that support Lazy Loading complex data entities can cause havoc with some VERY useful 3rd party libraries you can use in MVC like MiniProfiler and Glimpse, not to mention other issues when it comes to rendering these objects in forms for posting back later. So try to stick to flat ViewModels if possible.
I typically name my ViewModels according to their use. so my Register page may use a model called AccountsRegisterViewModel. However when I postback I usually use a different model called AccountsRegisterFormModel. This is because many times there is information I need to pass to render in the view but I really don't care about it (nor will it be present in most cases) on the action that accepts my postback. Also, MVC requires you to disambiguate your actions that use the same name via different parameters so using different view models helps there. For example CreateAccount() to show the account creation page and CreateAccount() that accepts your submission from the form. Though you can explicitly change where each form posts, the main focus with MVC is convention over configuration so I try not to change where forms post back to.
For your specific example of showing relevant information (Gold balance) you're likely going to want to create a Child Action with it's own view that would be responsible for doing it's own data access, or if you want to try your hand at ajax, have the balance be something handled in a smiple partial view that makes a call to a public action that returns JSON.
Those are the practices I've found have worked for me so far.
We're starting a new project, on the client side, we'll use a asp.net mvc3 application, accessing resources exposed by OpenRasta.
asp.net mvc has built in validation with Data Annotations, how usually people do validation with OpenRasta?
It depends the kind of validation you want. We don't currently support anything out of the box because the scenarios of what people wanted has always been very nebulous. People usually apply validation on the constructed model themselves rather than get OW to do it.
Happy to discuss your requirements and implement them as needed in 2.1, there's still a small open window for certain new features.
Asp.net MVC 3 preview 1 was released at the end of last month. Are there any new features you are excited about or any features you would like to see before it is fully released?
Full support for Controllers with Generic Parameters
public GenericController<SomeType> : Controller
Generic controllers are quite possibly the greatest MVC timesaver if your doing a lot or business CRUD. There are so many similarities between the Add methods of almost every MVC project that it makes sense to abstract these operations out in a Controller that fits all scenarios.
Right now its a little hacky to create a generic controller. The MVC engine always gets the name wrong (GenericCo vs. Generic) and without full support plugin and libraries that interact with controllers just fall over when they encounter a generic one.
Make Dropdowns easier to work with
As a professional MVC tag watcher I've noticed that working with dropdowns is one of the most repeated questions on SO. The amount of Dropdown questions is a strong indication that something should be done to make it easier or less ... complex?
make checkbox list easy to work with
add T4MVC to the official release
add official helpers for OData
support one javascript library either MS Ajax or jQuery(preferably)
I wish they can add something to help developer to migrate their previous ASP.NET WebForms application.