This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Entity Framework Validation
Is there any good and flexible validation framework for EntityFramework ?
Entity Framework provides a great variety of validation features that can feed through to a user interface for client-side validation or be used for server-side validation.
When using code first, you can specify validations using Data annotation or fluent API configurations.
Additional and more complex validations can be specified in code and will work whether your model hails from code first, model first or database first.
Here are some links for more details: Configuring Properties and Types with the Fluent API and Entity Framework Validation.
You could look at Fluent validation framework. It is not EF specific but means you can use it on viewmodels as well.
You can also look at foolproof validation it does client side validation for things like one property being required if another is true etc. E.g if married checkbox is checked you must add maiden name
Also look for data annotation extensions on nuget it extends what EF offers
Related
I am writing an asp.net mvc application with MEF to extending the application features, my data access is created by entity framework. In my scenario i must have ability to extend entity framework models with plugins that retrived with mef.
Each plugin may have their own properties to be added to the specified model/models. I have searched and can't find much information on the issue, if any one has any idea pleas help me to solve it.
The question in address: Adding A Custom Property To Entity Framework? is very different from my question, i want to any property that added to model be stored in (and retrive from) the database. And, new properties in my scenario must added in run time and must be retrived with MEF in a plugin.
This question already has answers here:
Mixing Fluent API and DataAnnotations in EF code first
(3 answers)
Closed 4 years ago.
I am coding our POCO entities in a Domain project in which I have no references to either EntityFramework or DataAnnotations. A second project, DataAccess, contains the data context and fluent configuration of entities.
Some entity properties are IsRequired or HasMaxLength. Developers using the Domain will not know what is required or if there is a maximum length of the property without Xml commented documentation. So, I've added documentation to the properties to convey the requirements.
The problem is, however, if a requirement changes I have to update the comments. This means that I'm updating 2 libraries - Domain and DataAccess.
I've been apprehensive in referencing DataAnnotations in the Domain; there are no attributes on my properties. These attributes would give a developer with access to the Domain entities knowledge of what is required or if there is a max length for a property.
Is there another way to convey property requirements for properties without using DataAnnotations on the entities or having to update the Xml comments on the entities?
Or, am I being unnecessarily thick-headed about adding the DataAnnotation reference to the Domain project?
I think it can be a good idea to leave your POCO entities without annotations and without including reference to EntityFramework.dll. Easier to create portable dll and reuse your model. That is, if you ever going to need it.
But as you said it makes it harder to have "auto documented" model. You could try with generating model diagram out of DbContext, there is a power tool for that. Maybe that will be enough for your documentation needs. I tried it on a model with >200 entities and it worked ok. For the diagram generation it took cca 2min but after that it worked ok and was useful for "documentation" purposes.
There are a lot of Sql table -> C# class methodologies, but I'm looking for the reverse.
Hypothetical situation:
I have N classes populated by some web service I consume, manipulate, then preform an action on. Now the boss wants said web service data persisted in a database.
I already have the classes defined, how can I quickly and easily (aka, lazily) generate a sql table off of each class?
Entity Framework and nHibernate both allow you to use them in "code-first" mode, which involves writing classes then generating databases.
There is a walk-through of this on ScottGu's blog here: http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
you can use MS Entity Framework Code First approach:
Code First allows you to define your model using C# or VB.Net classes,
optionally additional configuration can be performed using attributes
on your classes and properties or by using a Fluent API. Your model
can be used to generate a database schema or to map to an existing
database.
read more about it here: EF 4.1 Code First Walkthrough
Entity framework 4 has a code first development feature, I haven't used it so can't really recommend it
ScottGu blog
OK,
This is probably not simple but I figured I would throw it out there:
I get the idea of extending an Model-First entity in EF with a partial class to add data annotation elements somthing like this:
[Required]
string MyString {get;set;}
However, if I am in a multi-tenant system where I may want to customize which fields are actually required when passed to the end client can I dynamically set the annotation depending on how the client has configured the setting, say in another table for instance?
Update: In the multi-tenant system there are at least two databases. One that stores system configuration information. In addition each customer would have their own individual database. The system DB controls routing and selecting the proper customer database from there.
Any insights or ideas anyone has on how to accomplish this would be great!
Thanks,
Brent
If you are using EF 4.1, you could create different DbContexts, referencing the same entities, but provide different mappings using the Fluent Api.
Here is a link to a video that describes using the api.
Fluent Api
Note: Your database would need to be setup to accommodate all the different configurations. For example, if in one context, "FirstName" is required, and in another it is not, your db should allow NULL in order to cope with both situations.
You can't change attributes dynamically.
One option would be to crate the types dynamically, probably inheriting some class (or implementing an interface), that you actually work with. Although I'm not sure this would work with EF.
Another possibility is if EF had another way you could tell it the same thing, but I don't know EF much, so I can't tell if something like that exists.
I'm getting ready to start a new project and I've been researching the entity framework. My question is what is the best strategy for validating the entities? Other projects I've worked on have used attributes for most of the validation, but obviously this is not possible in the entity framework. Is the only way to do this by handling the partial methods in the property setters? All advice is much appreciated.
I have not actually used the Entity framework before but a quick search indicates that you have several options.
1) Validate at another layer in your application
Always an option, I just thought I would throw it out there explicitly.
2) Hook into the OnChanged events of the Entity then perform validation
Likely brittle and would become confusing/slow after if you have many different properties things that can change for each entity.
3) Implement partial methods to validate property changes
According to this post and this walkthrough there are partial methods available for validation. This seems like your best option as it is not very intrusive and you can selectively implement the validation you want.
I hope that helps. Good luck.
In .NET 4, there is going to be out-the-box validation support in Entity-Framework.
Check out: http://blogs.msdn.com/adonet/archive/2010/01/13/introducing-the-portable-extensible-metadata.aspx
So don't work to hard on implementing too complex validation logic...
If you use ASP.NET MVC, then you could use Validation Application Block or the System.ComponentModel.DataAnnotations. The articles Using Data Annotations and Using Application Block show how to do them using Linq, but the usage with entity-framework should be similiar.
We have overrident the object context and intercept the SaveChanges() method
public abstract class ValidationObjectContext : ObjectContext{
...
public override int SaveChanges(SaveOptions options){
ValidateEntities();
return base.SaveChanges(options);
}
}
That way the validation is left until the last minute before the connections are made but after you are (expecting) to be happy with the graph and ready to commit, (as opposed to other options to validation on any change, since some complex rules like those we have are only valid after several properties are set.). We have two levels of validation, Basic Property validation, things like string length, nullability etc. And Business Logic validation, which might require checking rules across multiple objects, possibly hitting the database to confirm.
If you are using WPF or Windows Forms then you might implement the IDataErrorInfo interface.
The BookLibrary sample application of the WPF Application Framework (WAF) project shows how entities created by the Entity Framework can be validated.
Consider implementing IValidatableObject in your entities.