Using the Entity Framework POCO Adapter

Not all of us get to use EF 4.0 like the cool kids.  Sometimes, you are on a project with a state government – for example – who won’t use a Microsoft product before its first service pack, much less Beta 2.  You are stuck with a product that everyone including Microsoft has agreed is a substandard effort – EF 3.5.

One of the big complaints about EF 3.5 is that the domain mode it provides is persistence aware.  This means that rather than just asking the framework for a class, say People, and getting a Person object back, you get a framework object with a bunch of extra database code in it that breaks the tenants of encapsulation.  At first blush, this seems like something that only people at MIT care about, but the fact is that when you change something about your database, you have to change all of these objects, which is a bad thing.

Anyway. I was tasked with finding a data layer technology for this big project.  I looked at NHibernate, and SubSonic, and a few others.  I looked at code generators like LLBLGen.  I ended up with EF 3.5 because I know I am going to want to go to EF 4 and there will be less recoding if I start with EF 3.5.  That’s basically it.

I still need persistence ignorant objects, though.  Enter the POCO Adapter.  This project is on code.msdn.com, and it written by people knowledgeable about how EF works.  It has a code generator that takes the EDMS file and generates Plain Old CLR Classes, and a customizable transport  layer.  Looks like it will work.

Getting the POCO Adapter and getting started

The EF POCP Adapter is available from code.microsoft.com.   It comes in both C# and VB, and has sample code and texts using Northwind.  The code generator compiles into a console application, and the adapter itself is just a strongly typed class file.

I started things out by generating an EDMX of SHARP, my sample conference management system.

image

Then I compiled the EFPocoAdapter project and was rolling.

Generating the domain model

I started by running the commandline utility on my EDMX file for SHARP.

EFPocoClassGen /inedmx:"C:\Users\Bill\Documents\Visual Studio 2008\Projects\SharpEdm\SharpEdm\SHARP
.edmx"  /outputfile:c:\sharp.cs

I added the resultant sharp.cs file to my project, referenced the EFPocoAdapter project in the solution,. and set up a project reference to clear up references to EFPopoAdapter and EFPopoAdapter.Classes.  Wow, it really does take a loong time for that dialog to come up.  Anyway, then I compiled.

Ran into a weird naming problem.  All of the generic PocoAdapterBase instances referenced the ConferenceDbModel, which is the namespace for the EDMX classes, and not SharpEdm, which was the actual class.  After discovering this, I discovered for the 10,000th time that it is a good idea to read the documentation first.  Doing that, I learned that there are some options I really should set.

  • /ref sets the compiled DLL that has the classes that I want to map to.  All I did was compile the EDMX file and use that DLL.
  • /map helped with my naming issue.

So the final command looked like this:

EFPocoClassGen
 
/inedmx:"C:\Users\Bill\Documents\Visual Studio 2008\Projects\SharpEdm\SharpEdm\SHARP.edmx" 
  /ref:"C:\Users\Bill\Documents\Visual Studio 2008\Projects\SharpEdm\SharpEdm\bin\Debug\SharpEdm.dll"
  /outputfile:c:\sharpAdapter.cs
  /map:ConferenceDbModel=SharpEdm

The tools it left me are pretty straightforward.  here is a look at them:

image

In the next post I’ll take a look at using them in this context.

Comments are closed

Bill Sempf

Husband. Father. Pentester. Secure software composer. Brewer. Lockpicker. Ninja. Insurrectionist. Lumberjack. All words that have been used to describe me recently. I help people write more secure software.

PageList

profile for Bill Sempf on Stack Exchange, a network of free, community-driven Q&A sites

MonthList