Best practice to implement business logic validation - Entity Framework

Question

I'm using Entity Framework for the first time, and I need to add business logic before inserting new objects into the db, here are the options I thought about:

1. Implement business logic on the DataContext level - by overriding SaveChanges method
2. Implement business logic for each entity using OnPropertyChanging partial method
3. Wrap the generated code in a custom class that implement the validation layer.

Which method is best practice when managing business logic on Entity Framework

Answer 1

Have a look at validation with EF - the validation is inside the entities themselves.

It's a very clean way to organise your project.

When you have POCOs, the obvious place for entity validation is in the POCO itself.

It makes sense that any validation of the Customer object is actually in the Customer class.

Answer 2

My experience:

1. This works but it is quite lot of work and in case of many entities which must be validated this can be slower. Actually EFv4.1 does this automatically.
2. I don't like this way - it serves only single property changes and doesn't work for complex validation where you need to modify several properties before you get a valid state.
3. Perhaps - I like validation on demands. Each entity can expose Validate method which will check that state of the whole entitiy is correct.

But all this works only if you always use the whole entity. Once you start to use partial updates and other features you will still have to handle validation elsewhere. That is another +1 for validation on demand.

Answer 3

I prefer a version of number 3. I like to abstract Entity Framework anyways using a repository or something similar, in case I want/need to replace EF in the future.

Then for validation/business logic, I use whatever validation techniques make sense for the application, but usually some combination of DataAnnotations (for UI minimum validation) and a validation framework like Fluent Validation for maximum validation/business rules. This validation/business logic lives in both the entity class (DataAnnotations) and in an abstraction layer, which is usually a service layer in my applications.

Answer 4

Article from Visual Studio Magazine addressing the issue:

http://visualstudiomagazine.com/articles/2012/04/01/integrating-validation-with-the-entity-framework.aspx

Answer 5

Maybe your answer stands in thoses lines ;)

Best practice entity validation in ASP.NET MVC & ADO.NET Entity Framework

Answer 6

Another way to consider is to fully componentize out your data access layer from your business logic layer completely.

Create a data access interface that only accesses Entity Framework directly, then in a seperate project I would create your business logic classes which interface with the data access layer through the interface. No Entity Framework referernces in your business logic project.

In this way the layers are componentized and easier to distribute as multiple assemblies for either two-tier or three-tier access.

Answer 7

maybe try to read about Specification pattern

Answer 8

You can allways extend your classes by creating another partial class definition, most EF templates define the Entities as partial definitions just for people to easly extend them. You will want to do this if you're working with WPF or Silverlight as most things are not bound directly, you either have a boolean and want to convert that into a color, etc. Writing converters is slow and requires a lot more code to setup then just creating new Getters on your BusinessObjects.

We have been using EF 4.0 STE (Self Tracking Entities) for a while now, and we extend most of them with our own partial definitions. We changed a bit of the T4 template that creates the STEs to allow access to constructor on the custom partial class definition and other small improvements.