I set out recently with the goal of creating a new module built on Entity Framework (EF) v4 for data access in DNN 5x using Visual Studio (VS) 2010.  While I read several articles (including Michael Washington’s and Benoit Sarton’s articles) about using EF on the .NET 3.5 platform in VS2008, I couldn’t find anyone online working with the sort of setup I wanted.  More importantly, I couldn’t seem to translate any of the documented methods I found.  Until now, that is.

EF4 has several features I wanted in my project, like direct access to foreign keys in the entity model, mapping the results of a SQL function to a complex data type, and self-tracking entities to help overcome the page lifecycle limitation.  VS2010 has all kinds of nice features that make development easier like better Intellisence and highlighting references, and of course it’s required for EF4.  DNN5 includes things like jQuery support and “normal” admin pages that will make life easier for me on this project.  All told, if I could figure out a way to fit these pieces together, I’d have a nice little setup.

While Michael Washington’s solution works as advertised, there were two things I didn’t really like about it.  First, his is a Web Site Project and my personal preference is to work with Web Application Projects.  Second, he’s placed the EDMX file in the AppCode directory which gives it some sort of special handling that, admittedly, I don’t completely understand.  I have a big learning curve in this project already and I didn’t want to tackle that as well.  Neither of these issues are really condemning by any means, they’re actually just me being lazy and stuck in my ways.  Regardless, I found Benoit Sarton’s solution, built from Gilles le Pigocher’s project starter method, easier to work with.  In the end, my solution looks like this.  As you can see, I’ve included the website just like Gilles does, I have several projects that align with the functional areas of my application, and I have a project named DAL for my EF model . 

The file system looks almost identical.  Everything sits in the DesktopModules directory, including the solution file.  So far, there is no difference between this solution the one Benoit documented.  A problem arises, however, when you try to add an EntityDataSource control to an ASCX document in VS2010.  There is no error, the EntityDataSource – Configure Data Source wizard simply can’t find the connection string in the Web.Config.  To be clear, this exact same setup works fine with .NET3.5 in VS2008.  In truth, there’s only one real difference between this “new” solution and the one Benoit described when it’s all said and done.  While I’ve referenced System.Data.Entity and System.Web.Entity as prescribed in Benoit’s article, I’ve changed the reference to System.Web.Entity, forcing it to pull the 3.5 version from the GAC.  This one, seemingly minor change is all that’s required to migrate this type of solution to VS2010 and (mostly) .NET4.  The resulting project file has the following reference section, replacing the reference to System.Web.Entity 4.0:

    <Reference Include="System.Web.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\..\Windows\assembly\GAC_MSIL\System.Web.Entity\3.5.0.0__b77a5c561934e089\System.Web.Entity.dll</HintPath>
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>

You might find that your hint path is different, depending on your file structure.

Can anyone tell me the drawbacks to such a solution?  In what ways is this short-sighted?  A better way to ask might be: is there any reason that I should not begin a project like this, given that I’ll need to maintain the application for some time to come?

Thanks for allowing my long winded description of a tiny change, and thank you very much for any feedback you can offer.

brandon haynes created a solution for Linq2SQL to support database owner and object qualifier - I would expect the same approach should work with EF4 as well. please check it out on Codeplex.

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

It’s good to have a blog post resurrected two years later !

If you remember EF was quite experimental at that time, and it was criticized by more experienced ORM users. In fact I was using it for windows applications, and I wanted to also give it a try on the web.

However I was a bit skeptical about using it as a full replacement for the native DNN data layers. I was (and am still) a bit anxious about an ObjectContext meeting a WebPage, View States and Sessions. What happens there is kind of black box to me, and I feel safer to trigger a good old SP that persists things to the DB when you decide it. Even in windows applications I find myself a bit compulsive with SaveChanges()

There was also that databaseOwner and objectQualifier issue that cooled down the idea to deploy modules in the wild with an embedded model.

In short there are potential issues having too many objects in memory in a web application, if they are not read only.

So I felt that the Store Module was a good example of a scenario where we want reliability for the front office, and therefore use Store Procs ; but you may want specific tools and queries for the back office, and EF would make things easier for the developer.

But I’m sure that with the latest EF versions (4 & 4.1); and more examples and patterns on the web, it must now be possible to use EF as the primary data access method for a module.

You might want to have a look at the nopCommerce project, that is using EF since version 1.90, and these guys are usually quick to adopt Microsoft new patterns.

LightSwitch is also an interesting way to use EF (also it’s in the background there); Michael Washington has interesting blogs about it:

http://www.dotnetnuke.com/Resources/Blogs/tabid/825/EntryId/3040/LightSwitch-and-DotNetNuke.aspx

Let us know when you publish your first 100% EF module!

---

Benoît Sarton
www.bsi.fr
www.dotnetnuke.fr