views:

1041

answers:

4

I'm trying to use the Repository Pattern with EF4 using VS2010.

To this end I am using POCO code generation by right clicking on the entity model designer and clicking Add code generation item. I then select the POCO template and get my classes.

What I would like to be able to do is have my solution structured into separate projects for Entity (POCO) classes and another project for the entity model and repository code.

This means that my MVC project could use the POCO classes for strongly typed views etc and not have to know about the repository or have to have a reference to it.

To plug it all together I will have another separate project with interfaces and use IoC.

Sounds good in my head I just don't know how to generate the classes into their own project! I can copy them and then change the namespaces on them but I wanted to avoid manual work whenever I change the schema in the db and want to update my model.

Thanks

+6  A: 

Actually the T4 templates in EF 4.0 were designed with this scenario in mind :)

There are 2 templates:

  • One for the Entities themselves (i.e. ModelName.tt)
  • One for the ObjectContext (i.e. ModelName.Context.tt)

You should put the ModelName.tt file in you POCO project, and just change the template to point to the EDMX file in the persistence aware project.

Sounds weird I know: There is now a dependency, but it is at T4 generation time, not at compile time! And that should be okay? Because the resulting POCO assembly is still completely persistence ignorant.

See steps 5 & 6 of this: http://blogs.msdn.com/adonet/pages/walkthrough-poco-template-for-the-entity-framework.aspx for more.

Hope this helps

Alex

Alex James
A: 

Hi Alex,

I have moved the POCOs to a separate project as described in the link you provided. I have several queries though:

  1. How do you force regeneration of the POCO entities after changing the model (I am working just with the model - no database) and without recreating the tt file? Right click on the model diagram worked previously of course.

  2. When compiling I now get this warning for each entity: 'Error 11007: Entity type XXXX is not mapped.'. This may relate to not having generated the database (?) but this was not happening previous to the move.

  3. Minor point but can you have the entity classes showing at the same level as the tt file rather than having to open this every time (or is this the equivalent of 'code behind')?

Cheers - great help btw.

Nick
+2  A: 

@Nick,

  1. To force the regeneration of the POCO entities, you just need to right-click the main .tt file and select "Run Custom Tool". This will force it to regenerate your POCO classes with your updated changes to the .edmx model.
  2. Is there any problem with you going ahead and Right-clicking the model and selecting "Generate Database from Model..." even though you aren't necessarily generating the database? That will most likely get rid of your 'Error 11007...'.
  3. I think it's equivalent to a "Code Behind". I don't know any more than that.

One other thing to note about the link that Alex gave. Once I moved my main .tt file to a different project, the file that was generated from the ".Context.tt" file would not compile because it was missing references to the POCO files that were located in a different namespace (because I wanted my ObjectContext to be in a different domain than my POCO files). I had to modify the ".Context.tt" file to had a using Poco.Namespace (where Poco.Namespace is the name of the namespace where the POCO files were generated). This then allowed my project to compile.

Joel

hjoelr
A: 

I've encountered a serious bug when using this approach combined with Dynamic Data projects and controls. Basically, you will get an error.

"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."

Josh Simerman