To remedy this issue, I have developed an adapter that converts the Entity Framework model generated by the designer into a DotNetNuke-compatible model that uses both the object qualifier and database owner specified by an end-installation.  This adapter is based off of the more generalized model adaptation framework that I recently released.

My goals for any satisfactory solution were as follows:

This solution extends the Entity Framework runtime model adapter to operate within a DotNetNuke extension, allowing a developer to design against an unqualified, dbo-owned DotNetNuke instance and be assured that it will deploy (and operate) correctly on any configuration that an end user might have deployed. Adaptation is largely inexpensive, and since the models are cached by type, performance is not significantly affected.

Click here to access the project site for additional details and downloads.  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

As always, feedback is greatly appreciated.

B

The ObjectContext is a base class for all Entity Framework models.  While there exists a rich API for interacting with a model, the ability to adapt the underlying schema to the (potentially varying) run-time environment presents a serious shortcoming for many production applications.  These variances can potentially involve myriad considerations, from a change in database owner to modified table names (often by a production-specific prefix).  This can have a serious impact on large-scale deployment of applications using the Entity Framework (those familiar with my DotNetNuke-related work will immediately understand this consideration, where a run-time environment may be configured to use an arbitrary database owner or table prefix).

To remedy this issue, I have developed an adaptive framework that converts an Entity Framework model generated by the Visual Studio designer into a highly configurable result.  This framework is designed to be flexible, extendable, and highly customizable.

My goals for any satisfactory solution were as follows:

• Run-time adjustment of an Entity Framework EDMX model, including:
  • Connection-based adaptation (e.g. use of a runtime-specified connection string)
• Run-time adjustment of model schema, including:
  • Adjusting data-level table prefixes or suffixes
  • Adjusting the owner of database objects
• Continued use of the Visual Studio Model designer
• No tedious changes in the compiler-generated code
• Continued use of an assembly-embedded EDMX model (and thereby no additional or external schema deployment files)

It is unfortunate that the object model exposed by the Entity Framework is so frustratingly difficult to extend.  The underlying metadata are overwhelmingly read-only (and, frustratingly, many potentially useful classes are either internal or sealed).  Indeed, it seemed that there was no simple remedy to the problem at hand.

My solution utilizes the following approach:

• A Connection adapter is used to walk a model (and optionally adapt a connection string based upon a run-time environment) [Goal 1].
• During the model walk, a dependency-injected model adapter is utilized to adapt various attributes of the model (currently storage, mapping, and association) [Goal 2].  Walking is reasonably inexpensive, and since the models are cached by type, performance is not affected.
• The framework requires only a change in base class to an AdaptingObjectContext (which itself derives from an ObjectContext).  This allows the Visual Studio editor to continue to be utilized, and no direct EDMX manipulation is required (though, frustratingly, the base class of an entity model is not adjustable through the Visual Studio UI, necessitating a change in the code-generated file) [Goal 3, 4, 5].

I use dependency injection to adapt attributed entities (database, table, and function names) into their adapted counterparts.  Additional adapters could easily be constructed for other domains, should any arise (to illustrate this point, a NonTransformingAdapter is included in the release, which performs no transformations).

Click here to access the project site for additional details and downloads.

As is all of my DotNetNuke-related work, this framework is available under a liberal open-source license for ready public consumption (and extension).  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

As always, feedback is appreciated.

B

Herein I describe with more specificity the use of the adapter generator and the resultant adapters, and announce the release of the first production-ready version of the adapter generator software.

To introduce the use of the IDataReaderAdapter generator, consider a hypothetical software package with a data-layer defined as:

Business-process code interacts with this data logic exclusively through the IDataLayer interface; this not only creates a clean separation of concerns, but also allows for run-time specification of arbitrary IDataLayer implementation (typically a la dependency injection).  This might be concretely implemented as:

For those developers wishing to move to Microsoft’s Entity Framework (EF), this presents a problem.  There is no ready method by which one may convert an EntityObject into an IDataRecord (and, similarly, an IEnumerable<EntityObject> into IDataReader).  Without such a conversion, it is not possible to transition to the EF without breaking the IDataLayer interface contract.  For those applications that are widely deployed (or have strong third-party augmentation), this is a very real problem indeed.

The IDataReaderAdapter generator allows for such a conversion in two ways:

1. Compile-time adaption an EF schema into a set of IDataRecord-implementing wrappers without the use of reflection (and of O(n) property-lookup performance), or
2. Run-time adaption of an EntityObject (or any) object to an IDataRecord-implementing counterpart through the use of reflection.

Note: The adapter generator may be used to adapt any objects into IDataRecord/Reader-implementing objects.  Though the functionality described herein largely deals with the EF, the generator may be applied against any arbitrary object.

Method 1: Compile-Time Adaption of an Entity Framework Schema

To produce IDataRecord/Reader-implementing adapters at compile-time, we execute the adapter generator utility and point it at our EF schema.  The utility is executed in one of two ways, with syntax as:

IDataReaderAdapterGenerator
        /entities:[.NET Entity Framework EDMX file]
        /output:[output class filename]
        [/entities:[entity regex]
        [/language:vb|c#]

IDataReaderAdapterGenerator
        /assembly:[source assembly filename]
        /output:[output class filename]
        [/objects:[entity regex]
        [/language:vb|c#]

• Entities/Assembly: Here, the first parameter may either be an EF Entity Data Model XML (EDMX) file or an arbitrary assembly.  The adapter generator will, assuming the former, parse the EDMX, extract entity objects, and create adapters.  If an assembly is specified, adapters are generated for each publicly-exposed object in that assembly.
• Output: This parameter specifies the output file for the generated adapters (i.e.; “Samples.cs” or “Samples.vb”).
• Entities/Objects: This setting specifies the particular entities or objects that are adapted.  This is specified as a regular expression (to adapt all entities or objects containing the word “Data” one would use the pattern “.*Data.*”).  By default, all available objects are adapted.
• Language: This allows specification of the target language for the generated adapters, either VB.NET or C#.

Method #2: Run-time Adaption of Objects

As an alternative to compile-time generation of IDataRecord/Reader-implementing objects, arbitrary objects may also be adapted at run-time.  Note, however, that this flexibility is achieved at the expense of the additional overhead required for the reflection used during access.  Consider this cost carefully — it is likely that compile-time adaption should be utilized wherever possible.

Utilizing IDataRecord/Reader Adapters

Irrespective of the method selected above, the resultant adapters are used in much the same manner.  By way of example, consider the data model that would result when the concrete DataLayer above were converted to utilize the EF.  This model would likely contain two entities, SomeData and SomeOtherData, and would be structured as follows:

If this EDMX existed in a file named SampleDataModel.edmx, we would adapt the model as:

IDataReaderAdapterGenerator /entities:SampleDataModel.edmx /output:AdaptedSample.cs

And we would implement our modern IDataLayer-implementing layer as:

Note the use of BrandonHaynes.Data.DataReaders.SomeDataDataReader and BrandonHaynes.Data.DataReaders.SomeOtherDataDataReader to adapt returned EntityObjects (context.SomeData and context.SomeOtherData.Where(…)) into IDataReader-implementing interfaces.

To adapt objects at run-time using reflection, we would substitute these per-object adapters with the use of BrandonHaynes.Data.ReflectedDataReaderAdapter (or ReflectedDataRecordAdapter).  This would, for example, read as:

   return new ReflectedDataReaderAdapter(context.SomeData);

Conclusion

Herein we described the command-line use of the IDataReader Adapter generation tool to produce IDataRecord and IDataReader-adapting objects.  These objects may be used to modernize provider-based data layers that heavily rely on these interfaces, without breaking the existing contract. 

The project site, in addition to the source for both generators, includes two samples that should be reviewed by those interested in implementing these techniques in a production environment.  The first includes a sample model similar to that described herein, while the second includes a sample DotNetNuke data provider.  We will revisit this latter sample in subsequent entries as we explore advanced applications of the generated objects.

This entry will be followed by an exploration in more detail of the actual generated IDataReader and IDataRecord-adapting objects, including a review of the actual generated code.  For compile-time generated objects property conversion is performed in O(n) time with the mere addition of a constant-time hash (and lazy-loaded initialization).

As always, comments and feedback are greatly appreciated.

B

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

² 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.