Self-Contained Entity Framework Models and ASP.NET Dynamic Data

In an earlier post, I wrote about the new awesomeness that ASP.NET 4.0’s Dynamic Data brings to many to many relationships.

I frequently notice that most DD demos demonstrate creating the data model within the same project as the DD website.

Even though a typical Dynamic Data app is for RAD development and isn’t focused on application architecture (come on, the data access is buried in the UI), I still can’t bare to store my model inside of the UI project. All of my EF Entity Data Model’s are housed in their own projects.

This is not a problem at all for a Dynamic Data site. Like any other project that leverages an EDM in a separate project, you only need to perform three steps to point to the external model:

  1. Add a reference to the project that contains the data model
  2. Add a reference to System.Data.Entity.dll
  3. If it’s the executing app (in this case it is), provide the EntityConnection string, most typically by adding it into the web.config file

For Dynamic Data, there is one additional consideration that I was torn over.

I have my model in it’s own project because I like to be able to reuse it in other applications.

In a DD site, I typically do  not expose the *entire* model for the scaffold (e.g., for use in the dynamic application). Instead, I set ScaffoldAllTables to false in the global asax file:

 DefaultModel.RegisterContext(typeof(MyEDM.MyEntities), 
new ContextConfiguration() { ScaffoldAllTables = false });

and explicitly mark the classes which I want to include with the scaffold attribute:

[ScaffoldTable(true)]

And here is where I run into the conundrum.

The ScaffoldTable attribute is something that I specifically want for the Dynamic Data site. It’s not needed by any other apps that might be using my model. The only way to add it to the generated class in my model project is to use partial classes. As far a I know*, partial classes need to be in the same project as the rest of the partial classes so that the compiler can pull them all together. That means, I’m forced to “dirty” my model project with the attributes that are meaningless to any other application that might also use my model. Fortunately, the ScaffoldTable attribute is in System.ComponentModel.DataAnnotations, not System.Web.DynamicData, so it doesn’t feel so bad. I suppose that because I’ve been focused on repositories and MVC lately, this is why I’m feeling so anal about this and perhaps it’s overkill.

My first instinct, because I was looking for separation, was to put the partial classes with the attributes into the dynamic data project, but of course I was quickly reminded by the error message telling me that I had ScaffoldAllTables set to false but I had not designated any classes to be used, that the extra partial class logic was not getting picked up by my classes because it was in the wrong project. So I bit my tongue and put them where they belonged, into the model’s project.

An approach that I’m considering is having different code generation templates for my model, so that I can generate entity classes to be used in different applications. Even so, I wouldn’t automatically mark all of the entities as a ScaffoldTable anyway. So I’ll have to think a bit more about that if I’m going to really worry about implementing it.

In the meantime, the key takeaway here is that you can have the model in a separate project to be used by Dynamic Data apps and you can specify which entities to use. You just need to include the partial classes with the ScaffoldTable attributes in the EDM’s project, not the Dynamic Data project where you might think you really want them to be.

*just a small caveat on the partial classes rule in case something changed in .NET 4.0 that I’m unaware of.  I don’t know how they would pull it off, but hey, you never know! 🙂

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

3 thoughts on “Self-Contained Entity Framework Models and ASP.NET Dynamic Data

  1. Hi Julie,

    I have the exact pain that you are describing, and an Entity Model that is currently shared across 3 applications.

    I came across this blog post: blogs.msdn.com/…/dynamic-data-sa

    Which offers a solution, to my eye it’s not a very pretty solution, but at least it keeps the DD metadata in the same project that consumes it.

  2. This does not work. I get this error with any kind of Dynamic Data wite or control the edmx file is not in the same project.

    Could not determine a MetaTable. A MetaTable could not be determined for the data source ‘EntityDataSource1’ and one could not be inferred from the request URL. Make sure that the table is mapped to the dats source, or that the data source is configured with a valid context type and table name, or that the request is part of a registered DynamicDataRoute.

Leave a Reply to Rob Dillon Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.