.net – ASP.NET and Entity Framework in Layered Architecture – using Entity Framework for ORM only

I've actually used your first approach with quite some success, but in a slightly different ways that I think would solve some of your problems:

1. Keep the entire schema and scripts for creating it in source control so that anyone can create the current database schema after a check out. In addition, keep sample data in data files that get loaded by part of the build process. As you discover data that causes errors, add it to your sample data to check that errors don't re-emerge.

2. Use a continuous integration server to build the database schema, load the sample data, and run tests. This is how we keep our test database in sync (rebuilding it at every test run). Though this requires that the CI server have access and ownership of its own dedicated database instance, I say that having our db schema built 3 times a day has dramatically helped find errors that probably would not have been found till just before delivery (if not later). I can't say that I rebuild the schema before every commit. Does anybody? With this approach you won't have to (well maybe we should, but its not a big deal if someone forgets).

3. For my group, user input is done at the application level (not db) so this is tested via standard unit tests.

Loading Production Database Copy:
This was the approach that was used at my last job. It was a huge pain cause of a couple of issues:

1. The copy would get out of date from the production version
2. Changes would be made to the copy's schema and wouldn't get propagated to the production systems. At this point we'd have diverging schemas. Not fun.

Mocking Database Server:
We also do this at my current job. After every commit we execute unit tests against the application code that have mock db accessors injected. Then three times a day we execute the full db build described above. I definitely recommend both approaches.

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!