Best Practice for Testing Business Logic - Entity Framework

Question

I am using Entity Framework for the first time and I need to add business logic before inserting new objects into db, here are the options that I was thinking about:

• Implementing business logic at the DataContext level - by overriding the SaveChanges method
• Implementing business logic for each object using the OnPropertyChanging partial method
• Wrap the generated code in a custom class that implements the verification level.

What is the best practice for managing business logic in the Entity Framework?

Answer 1

See validation with EF - validation is done inside the objects themselves.

This is a very clean way to organize your project.

When you have POCO , the obvious place to authenticate the object is in POCO itself.

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

Answer 2

My experience:

• This works, but it is quite a lot of work, and in the case of many objects that need to be checked, it can be slower. In fact, EFv4.1 does this automatically.
• I don’t like this way - it only serves individual property changes and does not work for a comprehensive check when you need to change several properties before you get the correct state.
• Maybe - I like the check on the requirements. Each object can set the Validate method, which will check the correctness of the state of the entire system.

But all this only works if you always use the whole object. After you start using partial updates and other functions, you still have to process the check elsewhere. This is another +1 for on-demand verification.

Answer 3

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

Then, for validation / business logic, I use any validation methods that make sense for the application, but it is usually a combination of DataAnnotations (for Minimum UI Validation) and validation frameworks such as Fluent Validation for maximum validation / business rules. This validation / business logic lives both in the entity class (DataAnnotations) and in the abstraction layer, which is usually the service level in my applications.

Answer 4

Maybe your answer is in the lines;)

Entity authentication in ASP.NET MVC and the Entity Framework ADO.NET

Answer 5

Another way is to completely isolate the level of data access from your business logic level.

Create a data access interface that will directly access the Entity Framework, and then in a separate project I would create business logic classes that interact with the data access level through the interface. No Entity Framework does not reference your business logic project.

Thus, layers are components and are more easily distributed as several assemblies for two-level or three-level access.

Answer 6

maybe try reading the spec template

Answer 7

You can always extend your classes by creating another definition of a partial class; most EF templates define objects as partial definitions only for people to easily extend them. You will want to do this if you are working with WPF or Silverlight, since most things are not directly related, you either have a boolean value, or you want to convert it to color, etc. Writing converters is slow and requires much more code, then just create new getters in your BusinessObjects.

We have been using EF 4.0 STE (Self Tracking Entities) for a while, and we are expanding most of them with our own partial definitions. We slightly modified the T4 template that STE creates to allow access to the constructor to custom define a partial class and other minor improvements.

Answer 8

Visual Studio Magazine article on the issue:

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