You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

~ Archive for Entity Framework (EF) ~

Released: DotNetNuke Entity Framework Model Adapter


The Entity Framework ObjectContext allows for development using a model automatically generated by a Visual Studio designer. However, when deployed within DotNetNuke, these attributes do not pick up the database owner and object qualifier required for correct inter-operation.  Because of this, large-scale deployment of modules using the Entity Framework is infeasible, and modules using the technology are unfortunately limited to internal applications.

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:

  • Run-time adjustment of an Entity Framework EDMX model to conform to any given DotNetNuke installation, including:
    • Connection-based adaptation (e.g. use of a runtime-specified connection string)
  • Run-time adjustment of model schema to effectuate:
    • Adjusting data-level table and stored procedure prefixes to match the DotNetNuke installation ObjectQualifier
    • Adjusting the owner of database objects to match the DotNetNuke installation DatabaseOwner
  • 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)

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.


Released: Entity Framework Runtime Model Adapter


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.


Using the Entity Framework (LINQ to Entity) to IDataReader Adapter


In a recent article, I developed a theoretical basis for an adapter that allows for the adaptation of Entity Framework (EF) entities into IDataReader-implementing form, and announced the preview availability of this software. 

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.


First Look: An Entity Framework (LINQ to Entity) to IDataReader Adapter


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. 


Log in