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.
B
Andy B.
September 11, 2009 @ 8:24 am
This project looks pretty cool. There seems to be a problem though. I don’t know if it is the project or just EF playing games on me though. Every time I try to run an EF query (or linq to sql query) based off your linq project, I keep getting some funky errors. Since you made the project, I thought I would seek your help trying to get it to run. For the entire thread on DNN forums, see http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/118/threadid/329554/scope/posts/Default.aspx. If you could send directly to my email with some ideas?
Brandon Haynes
September 11, 2009 @ 8:40 am
Hi Andy,
I’ve responded on the linked thread. If you could open a work item with enough data to fully reproduce the issue (e.g. files and schema) after ensuring that the problem is caused by the adapter, I’ll be happy to investigate a remedy!
B
João Rosa
January 2, 2010 @ 9:39 pm
Hi.
I work with all 3.5 features (EF, WCF & WWF 🙂 ) and start to update my DNN modules…
In the beginning I’ve and error in server, then I clean the database, the code files I upload again and run wells…
In the middle I’ve try your dll’s, but don’t work like “normal” EF…
My question is, what’s the advantaged to use your project? And if you want to reproduce my module I’ve send you the files! 🙂
Congratulations for your project, João Rosa
Brandon Haynes
May 15, 2010 @ 11:03 am
The big advantage to the model adapter is that it allows for an adaptation of the entity model at runtime. This means that you may make changes to the model that did not exist at design time. In a DotNetNuke context, this means you can support differing object qualifiers and database owners on client installations, where these values are unknown at compile time.
For initial development and internal deployment, the DotNetNuke model adapter might not be what you need, though the model adapter might offer some functionality not available in vanilla EF.
Hope this helps!
B