Using Entity Framework entities as business objects?

Question

First off, with 11k question views at the time of this writing, I'm a little surprised by the lack of answers and with all due respect, the quality of the answers, given a fairly straightforward question.

So, now that I've vented a little bit, I'd like to address this question(s) because I think that it applies even more so today with the recent release of Entity Framework Code-First.

"Using Entity Framework entities as business objects?"

A couple points of clarification before I began:

• When you say "business objects", I'm under the impression that these objects you refer to contain rules or logic ranging from, for example, simple validation (I.e required fields) to more complex logic (I.e. processing tax on a checkout).

• I do not think that I can answer your follow up question regarding WCF. The reason for this is simply because I'm going to objectively answer your questions about EF as business objects which would then subjectively force me to take a stance proving contradictory of my attempt to genuinely and objectively answer said first question.

That said, onto your EF as business objects questions...

"I'm using Entity Framework O/R mapper from Microsoft and using entity classes (generated classes that are mapped to DB objects) as a business objects. Is this OK?"

Sorry, there simply is no right or wrong answer here. It depends on what your objective is and what you conclude to be the most reasonable design while fully understanding the advantages and disadvantages of doing so.

“Please state your cons or pros”

I’m glad you asked! I’ll be happy to answer and my hope here is that given the pros and cons you are able to make an informed decision as to whether or not you believe using EF for your business objects is “OK”. Typically, I’d break out the pros and cons making it easy to “digest”, however, I don’t think that is appropriate here because I think we’d be doing an injustice to such a very interesting topic which is also near and dear to my heart.

First off, let me talk technically for a moment… You are able to use EF objects as your business objects there is nothing technically preventing you from doing so. As a matter of fact, EF Code-First (CF) makes this incredibly easy by allowing you to create POCOs and giving you the ability to apply data annotations for simple validation as well as implementing IValidatableObject for more complex validation. Pretty cool, eh?

Therein lies the heart of the discussion.

EF, or any ORM, is designed to support data management. Its main responsibility is data and therefore the objects you create are data centric. So, if you are attempting to also design your objects by behavior then you have a little bit of a conundrum on hand. In a nutshell this conundrum is called impedance mismatch. Picture this; you have two required use cases in your application:

1. A screen to edit a user
2. A control to display a read-only subset of user information

If using EF (any flavor), or any ORM for that matter, you might gravitate towards using the same “User” object to handle the ability to save a user as well as fetching a user to pull the subset of read-only fields. You probably do so for one of a few reasons:

1. Like many developers, we have this seed planted in our brains during education “consolidating code” is of utmost importance or perhaps better known as DRY – Don’t Repeat Yourself, and therefore you may look at duplication of code, such as properties, in a negative context.
2. ORMs, such as EF 4.1, have technical limitations (and hackish work-arounds) such as mapping multiple POCOs/objects to the same database table thereby forcing you to regardless of your beliefs.
3. It is a quick and easy way to get an application up and running
4. It “feels” like the right thing to do

There are advantages and disadvantages of doing so and you could look at this is either a positive or negative way depending on your opinion.

I suppose if you believe in the normalization of code over behavior than you have succeeded greatly. You were able to limit the amount of code, potentially saving time, by writing a single object to handle your data and business use cases for that entity.

And I suppose if you believe in the normalization of behavior over code than you have failed miserably. By saving on code you have sacrificed designing objects by their responsibilities potentially making it difficult to manage and subsequently increasing the cost to maintain.

Regardless of your opinion we can probably all agree that this business object has taken on multiple responsibilities and the behavior (not data!) of the object is secondary at best. Its main responsibility is the management of data and its secondary responsibilities are the processing the business rules, both simple & complex, involved with editing a user and displaying read-only user information. In object-oriented design (OOD), if the design of an object is characterized by its identity and behavior, than this object might be one confused individual as it doesn’t adhere to the very definition of OOD.

Something to consider from a technical standpoint, any time you request the user object you inherit a significant amount of overhead. This might include things such as all the properties and business rules when only displaying a subset of read-only information.

So what does all of this have to do with whether or not I should use EF to represent my business objects?

Well… While it is technically possible, there are differing philosophies (some good, some bad) on whether or not you should use EF, or any ORM, to represent your business objects. I gave a synopsis aimed at the heart of these philosophies above, but they are documented in much more detail by individuals such as Rocky Lhotka and Martin Fowler.

The direction you take will most likely depend on the application and from a philosophical view, may depend on how much of an idealist or pragmatist you are. That said, I am not implying that one being an idealist or pragmatist correlates to either using EF for business objects or not – it’ll simply impact your take on this.

As of this writing, indications by Microsoft are that EF are built to handle business logic and, right or wrong, they appear to moving more in that direction. EF is ever evolving and certain technical limitations are being lifted such that EF may eventually be used to satisfy the best of both worlds. In other words, eventually you may be able to have your cake and eat it too.

Hope this helps.

Off to answer a question on whether or not persistence ignorance with an ORM is ridiculous considering the purpose behind it is to manage data. :-) Sorry, I couldn’t resist!

I am using EF in this fashion and one nice feature is that generated entities are partial classes, allowing them to be extended in a way that is fairly protected from regeneration issues.

Also take a look at this link on MSDN which describes some common usage scenarios with EF in regards to Business Logic.

The Entity framework was designed for the entity objects to be used as business objects, but you should keep in mind that the business objects will be tied to O/R technology as well as the EDM model. In EF 1.0, there wasn't any support for persistence-ignorance scenarios, but support was added in 4.0. You can implement interfaces, if you don't want to use any of their base classes.

As of .NET 3.5 SP1, they should also be usable as paramater and return types in WCF service methods without any additional code.

In my experience, we've used EF objects within the business layer of our application, but when we make the transition into the presentation layer through our WCF service layer, we will create view objects from the EF objects.

In our case, only the view is passed to the presentation layer. We do this to control how the data is presented and apply defensive validation for data coming in from the presentation layer.

In the case of ueing EF objects in the WCF transaction, you'll lose the object context that the EF object was associated. There are some efforts in CodePlex that try to help with this but I havn't kept up with their efforts.

Two limitations to be aware of that I have run into are:

1. Inherited Objects cannot have Navigation Properties - i.e. if you have a "person" class and then a "customer" and "supplier" those customer and suppliers cannont have Navigation properties.

2. Methods and Calculated Fields (anything in the partial classes) are not transmitted over ADO.Net Data Services - if you are also using ADO.Net Data Services anything you expand the Entity Framework objects on in partial classes will not be transmitted over ADO.Net Data Services.

These are generally not show-stopper items (for navigation properties we just don't use inheritance on entity framework, for now), but might be something of interest to yourself. I'm holding out hope that a future release will enable both of these items.