Using entities from Entity Framework as business objects?

.net architecture entity-framework


I'm using the Microsoft Entity Framework O/R mapper and employing entity classes as business objects (generated classes that are mapped to DB objects). Is that okay? Please include any drawbacks or benefits. How do I communicate such objects as data members in a WCF communication scenario between the business layer and presentation?

10/20/2008 12:59:44 PM

Accepted Answer

The fact that created entities are partial classes, which enable them to be expanded in a manner that is somewhat safe from regeneration concerns, is one wonderful aspect of EF that I am exploiting in this approach.

Also have a look at this MSDN link, which outlines some typical EF Business Logic use situations.

10/22/2008 7:52:28 PM

Popular Answer

First off, considering that the question has had 11k views as of this writing, I'm a bit shocked by the paucity of responses and, with all due respect, the caliber of those responses, given that it is a rather simple one.

So, now that I've let off a little steam, I'd want to respond to this topic or questions since I believe they are still relevant today, especially in light of the recent release of Entity Framework Code-First.

"Using Entity Framework entities as business objects?"

Before I continue, a few clarifications:

  • I believe that when you speak to "business objects," you mean items that include rules or logic ranging from, for instance, simple validation (such as necessary fields) to more intricate logic (I.e. processing tax on a checkout).

  • I don't believe I can respond to your follow-up query about WCF. The simple reason for this is because I'm going to really and objectively respond to your inquiries regarding EF as business objects, which will compel me to adopt a position that is in direct opposition to my endeavor to genuinely and objectively respond to stated initial question.

After that, I'll answer your queries on EF as business objects.

"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?"

I'm sorry, but there isn't a right or incorrect response to this. It depends on what your goal is and what you choose to be the most logical design after carefully considering the benefits and drawbacks.

“Please state your cons or pros”

I'm pleased you inquired! I'll be pleased to respond, and my aim is that by weighing the advantages and disadvantages, you'll be able to decide for yourself whether or not you think utilizing EF for your business objects is "oeOK." Normally, I would list the advantages and disadvantages to make the issue easier to "digest," but I don't believe it is appropriate in this case since I feel like we would be doing a disservice to such a fascinating subject that is also so personal to me.

Let me first briefly discuss a technical point. There is nothing technically stopping you from using EF objects as your business objects, thus you are free to do so. In reality, EF Code-First (CF) makes this exceedingly simple by enabling you to generate POCOs, allowing you to implement IValidatableObject for more advanced validation, and letting you to apply data annotations for simpler validation. Really nice, huh?

The discussion's core is found in that statement.

Any ORM, including EF, is made to facilitate data management. Data is its primary role, thus the objects you design will be data oriented. So, if you're trying to build your objects by behavior as well, you may find yourself in a bit of a pickle. This problem is known as impedance mismatch in a nutshell. Imagine that your program has two necessary use cases:

  1. a user editing screen
  2. a button that shows a read-only subset of user data

When using EF (of any flavor) or any ORM, you could be drawn to utilizing the same "oeUser" object to handle both the ability to save a user and the ability to fetch a user to get the subset of read-only information. You likely do it for one of the following motives:

  1. Consolidating code, or maybe better known as DRY â€" Don't Repeat Yourself, is of the highest significance, and like many developers, this idea is ingrained in our minds throughout school. As a result, you could see code duplication, such as properties, negatively.
  2. Despite your moral convictions, ORMs like EF 4.1 force you to map many POCOs/objects to the same database table because to technological restrictions (and shoddy workarounds).
  3. It is a fast and simple method to launch an application.
  4. It "feels" proper to act in this manner.

There are benefits and drawbacks to doing this, and depending on your viewpoint, you might see it either positively or negatively.

If you consider the normalization of code over behavior to be true, I guess you have achieved remarkable success. By building a single object to manage your data and business use cases for that entity, you were able to reduce the amount of code and maybe save time.

And I assume you have failed badly if you think that behavior should be normalized across code. By sacrificing design in order to save on code, you may have made objects more challenging to manage and hence more expensive to maintain.

Regardless of your viewpoint, I think we can all agree that this business entity has several roles, and its behavior (not its data!) is at best incidental. Its primary duty is data management, and its auxiliary duties include processing the basic and sophisticated business processes involved in modifying a user and presenting read-only user information. If an object's identity and behavior are what define its design in object-oriented design (OOD), then this object could be a little puzzled as it doesn't fit the definition of OOD.

From a technological perspective, you should keep in mind that every time you request the user object, you impose a significant overhead. When just presenting a portion of read-only information, this may contain things like all the properties and business rules.

What does this have to do with deciding whether or not to utilize EF to represent my business objects, then?

Although it is theoretically conceivable, there are many schools of thought on whether or not you should use EF, or any ORM, to represent your business objects. Some of these schools of thought are excellent, while others are terrible. I briefly summarized these concepts above, but others like Rocky Lhotka and Martin Fowler have written far more in-depth analyses of them.

Your decision will likely be influenced by the application and, from a philosophical standpoint, by how much of an idealist or realist you are. Having said that, I'm not arguing that using EF for business objects corresponds with being an idealist or pragmatism; it just affects how you see the situation.

Microsoft has made it clear that EF is designed to handle business logic as of this writing, and whether this is correct or not, they seem to be heading more and more in that way. Since EF is always changing and certain technological constraints are being removed, it may someday be utilized to fulfill the best of all possible worlds. In other words, you could ultimately be able to enjoy both cake and ice cream.

Hope this was useful.

Off to respond to a query on if persistent ignorance with an ORM is absurd given that it is intended to handle data.:-) Sorry, I couldn't help myself.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow