Flippant Remarks about Wrapping Entity Framework with a WCF Service
I should know by now that MVVM is the theory that allows a developer to approach WPF with a decent plan. Sadly, the current release of Microsoft’s Entity Framework is full of great theories but the one that is most needed (for me and a few thousand others), Persistence Ignorance, is not supported. Here in the rasx() context, persistence ignorance, means that plain-old .NET objects can represent data from a database (a persistent store) while being completely ignorant of it. This is ideal for test coverage, loose coupling, simplicity and elegance.
I found out that Entity Framework was lacking so much elegance when I used it to back a WCF façade—while WCF met my meager expectations. My notes:
- NHibernate does not have Persistence Ignorance problems. But avoid XML configuration hell with Fluent NHibernate—an idea started by C# MVP and StuctureMap architect, Jeremy Miller.
- This post, “Persistence Ignorance in the Entity Framework,” in the Data Platform Development Forums represents a great historical moment (from two years ago) when the developers complain directly to attentive folks at Microsoft.
- “ADO.NET team blog : Sneak Preview: Persistence Ignorance and POCO in Entity Framework 4.0”—the title speaks for itself…
- Aleem Bawany: “The Entity Object violates the Single Responsibility Principle because other than representing a Person it takes on the additional responsibility of managing data persistence.”
- Persistence Ignorance (POCO) Adapter for Entity Framework is available for the current release of Entities Framework. This project came to me from stackoverflow.com.
- Frans Bouma, via Paul Gielens (rightfully) defends the technical achievements in Java when confined to this specific issue: “Be aware that the .NET world isn’t comparable with the java world. In the java world, there are standards like EJB-CMP, so having POJO objects is key. In .NET it’s not, you need non-POCO objects to get decent databinding, remoting and xml serialization (cyclic references, interface types etc.)…” This defends comes to us from year 2005…
- I got a
System.ServiceModel.CommunicationException, “The underlying connection was closed: The connection was closed unexpectedly.” It appeared to be related to attempting to emit a composite object without[DataContract]attributes. - I found hard, clear limitations in LINQ to Entities. A guy named Moses who really lives in Egypt, Muhammad Mosa, found the same limitation over a year ago: “By design, LINQ to Entities requires the whole LINQ query expression to be translated to a server query. Only a few uncorrelated subexpressions (expressions in the query that do not depend on the results from the server) are evaluated on the client before the query is translated. Arbitrary method invocations that do not have a known translation, like
GetProducts()in this case, are not supported…” - While writing LINQ queries, I was tempted for a few seconds to attempt to implicitly cast an anonymous object to an interface. Did not work out because anonymous types “…cannot be cast to any type except for object.”It turns out that my previous use of the concepts I call output definitions, input definitions and data transfer contracts apply to this WCF solution. I tend to think that my .NET 2.0 approaches are either obsolete or auto-magical in the .NET 3.5 world. Not all the time…