Entity Framework, Business Objects and Beyond…

Back during the RMI days, we used to generate skeleton (henceforth referred to as skel or skels) and stubs for all long range service communications… Yes… WCF has its roots there and perhaps further into the past…! Details available here.

Looking at it from an architectural perspective, the data contracts were designed in such a way that the changes are minimal because every change in the stub would have to trickle down all the way to the client.

We have come a long now and Service Oriented Architecture is something that must be considered in any well behaved and decent enterprise application. In an environment such as this, I wouldn’t ever suggest having client dependencies on any 7 letter word starting with an ‘s’ ending with an ‘e’ and having ‘ervic’ in between.

We should think about providing all client apps independence so that any server / database / service changes do not affect the client… to a great extent…

Now there is a big discussion going on across the Internet about whether business objects should be separately created or should we treat EF entities as business objects. After all that’s what they are. Business Objects carry data from the client to the server and back and that’s what EF entities do… really really well… with all those amazing features such as state management, change tracking, yadda yadda… “straight out of the box” as they call it…

“Well couldn’t I agree more. But wait… entities are created from the database right…? using the EF Designer…?”

“Yes… and you could create in a number of other ways…”

“Well… doesn’t that mean that the design of my business objects would be dictated by the database design?”

“Of course not… Hell no… it is not necessary that you have to import all the entities from the database straight… of course you have the choice to customize them… manually…”

“Hmm… That’s nice… so now I can create my business objects with inheritance and everything just as I want them to and then map it to my database… True Object Relational Mapping…”

“Umm… Wait… did you say Inheritance… well you have that exception… you see the entities are already inherited from ObjectContext. And since there is no true multiple inheritance… you have that constraint… At least not in Framework 3.5… I don’t know if that would be available in Framework 4.0 either…”

“Ok… so what if the structure of the entities change…”

“Well all you have to do is regenerate the proxies and you are done…”

“Umm… new proxies…? Do you mean a change in the data contract…? what if I am not consuming the change… Like I have first name and last name in one of my screen and I don’t need the middle name although, i need it somewhere in the server… Do I still have to break the data contract…?”

“Err… Yes…”

Precisely why you should not be using Custom Entities or EF entities as business objects. You might be able to solve all your problems using partial classes and all code customizations… But end of the day, you are breaking the dependency rule.

There’s a reason why they call it a Data Contract.

The solution would be to create a separate business objects layer and then map your business objects with the EF entities. There are a couple of really smart implementations available. One of them could be implementing the Observer Design Pattern so any change could be tracked and reacted to.

Speaking of which I just discovered a good video in which Eric Meijer talks about the Reactive Framework. Definitely worth a watch.