Geeks With Blogs

News

View Anthony Trudeau's profile on LinkedIn

Add to Technorati Favorites


Anthony Trudeau

The Entity Framework has been valuable to me since it came out, because it provided a convenient and powerful way to model against my data source in a consistent way.  The first versions had some deficiencies that for me mostly fell in the category of the tight coupling between the model and its resulting object classes (entities).

Version 4 of the Entity Framework pretty much solves this with the support of T4 templates that allow you to implement your entities as self-tracking entities, plain old CLR objects (POCO), et al.  Doing this involves either specifying a new code generation template or implementing them yourselves.  Visual Studio 2010 ships with a self-tracking entities template and a POCO template is available from the Extension Manager.  (Extension Manager is very nice but it's very easy to waste a bunch of time exploring add-ins.  You've been warned.)

In a current project I wanted to use POCO; however, I didn't want my entities in the same assembly as the context classes.  It would be nice if this was automatic, but since it isn't here are the simple steps to move them.  These steps detail moving the entity classes and not the context.  The context can be moved in the same way, but I don't see a compelling reason to physically separate the context from my model.

  1. Turn off code generation for the template.  To do this set the Custom Tool property for the entity template file to an empty string (the entity template file will be named something like MyModel.tt).
  2. Expand the tree for the entity template file and delete all of its items.  These are the items that were automatically generated when you added the template.
  3. Create a project for your entities (if you haven't already).
  4. Add an existing item and browse to your entity template file, but add it as a link (do not add it directly).  Adding it as a link will allow the model and the template to stay in sync, but the code generation will occur in the new assembly.
Posted on Monday, April 19, 2010 2:56 PM .NET | Back to top


Comments on this post: Storing Entity Framework Entities in a Separate Assembly

# re: Storing Entity Framework Entities in a Separate Assembly
Requesting Gravatar...

This is OK. However, it is not ideal because it creates a circular dependency state. For example, suppose we have a typical Repository pattern. BusLayerProj1 has the DataContext and the BusEntityManagers. BusLayerProj2 has the BusEntities. In BusLayerProj2, a linked file points back to BusLayerProj1. As such, we have the 1st part of the circular dependency-- BusLayerProj2 has a dependency on BusLayerProj1. At the same time, BusLayerProj1 must know about the entities, because EntityManagers manage Entities, so BusLayerProj1 has a reference pointing to BusLayerProj2. As such, we have the 2nd part of the circular dependency, BusLayerProj1 has a dependency on BusLayerProj2. This causes a further problem when trying to use source control. A better way, is to move the TT file to BusLayerProj2 and change the internals as shown here http://www.codeproject.com/Articles/133689/How-to-Separate-Self-Tracking-Entities-to-Their-Ow which shows "How to Separate Self-Tracking Entities to Their Own Class Library", where the actual files get generated in BusLayerProj2, which is where they actually should exist. HTH. Thanks. -- Mark Kamoski
Left by Mark Kamoski on May 14, 2012 8:55 AM

# re: Storing Entity Framework Entities in a Separate Assembly
Requesting Gravatar...
But my question , Why to separate?
Left by Datta on Aug 28, 2014 7:42 AM

Your comment:
 (will show your gravatar)


Copyright © Anthony Trudeau | Powered by: GeeksWithBlogs.net