From the Desk of Brandon Haynes

Microsoft’s Entity Framework (EF) introduces a new data design paradigm within .NET. This framework, however, can be difficult to implement in projects that internally rely heavily on the exchange of IDataReader-implementing objects between layers (or within interface contracts). This is a shortcoming that is not easily overcome, especially without a standardized method with which to convert EF entities into an object implementing this interface. In many ways, migration of these projects to the Entity Framework is an all-or-nothing proposition.  This is a shortcoming that begs for remediation. 

Indeed, it would be advantageous to provide adaptation for entities within an EF/LINQ to Entity (L2E) model that was usable in such a legacy system. New code could directly utilize entity classes, while legacy interfaces could function as before. Such a system could be incrementally converted to a full EF implementation. This incremental approach has many practical advantages.

Herein (and over the next few related entries) is described an approach that resolves this shortcoming.  In its current form, it exists as a new layer at the top of the EF stack, as depicted in Figure 1 (right).  This layer is responsible for adapting EF entities to objects that implement the IDataReader¹ interface.

The resultant adapted IDataReaders may be used in any way, include across layers, so long as the underlying entities expose those properties expected by a consumer (including exposure through direct entity relationship).

Accordingly, the primary goals for this project include the following:

• Provide a per-entity adapter for each entity in a model, where each adapter implements the IDataReader and IDataRecord interfaces for use in legacy systems.
• The resultant IDataReaders should be internally strongly-typed and performant (and thereby not use reflection²).
• Model adaptation should be straightforward and easy to update as the model itself changes.
• Adapters should expose all entity properties, including “flattened” properties established through entity relationships (as exposed through conceptual model NavigationProperties).

These objectives are best accomplished through code generation.  This has the attractive characteristics of: compile-time validation, multiple-language targeting, model synchronization on a per-compile basis, performance gains, and strongly-typed code (an advantage given that an entity contains an arbitrary set of unknown properties).

Once adapted, we may construct a function that converts an entity (or set of entities) to an IDataReader-implementing construct, with code of the following general form: 

Over the next few entries, we (i) describe use of the IDataReaderAdapter generation tool, (ii) investigate the generated IDataReader-implementing adapters in more detail, (iii) generate and discuss performance metrics, and (iv) implement a case-study utilization of adapter generation (demonstrating a database-agnostic DotNetNuke hybrid data provider).

This project is available for public evaluation and consumption here³.  It is distributed with a liberal source license for use in production environments. 

For any that find this approach useful, or for those with additional questions, comments, or constructive criticism, I ask that you provide feedback here (or at the CodePlex site).  Your assessments and observations are an important part of any continued development.

B

¹ Though this entry often refers to the IDataReader interface, the approach described herein may also be used to generate IDataRecord-compatible objects.  This latter contract may be substituted for the former in most every reference herein.

² For types not known at compile-time, we include a reflection-enabled adapter.  Note that such an adapter may be used to adapt any object, including non-EF entity objects.  This additional flexibility is achieved at the expense of overall performance.

³ Project is expected to go live on or about December 15th, 2008.

Be Sociable, Share!

• 
•