Creating POCO classes in different project projects using the Entity Framework model

Question

I am trying to use repository template with EF4 using VS2010.

To this end, I use POCO code generation by right-clicking on the designer of the entity model and clicking "Add code generation element". Then I select the POCO template and get my classes.

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

This means that my MVC project can use POCO classes for strongly typed representations, etc., and should not know about the repository or have a link to it.

To connect everything together, I will have another separate project with interfaces and IoC.

That sounds good in my head. I just don't know how to create classes in my own project! I can copy them and then change the namespaces, but I wanted to avoid manual work whenever I change the circuit in db and want to update my model.

thank

Answer 1

In fact, the T4 templates in EF 4.0 were designed with this scenario in mind :)

There are 2 patterns:

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

You need to put the ModelName.tt file in the POCO project and just change the template to point to the EDMX file in the persistence-enabled project.

Sounds weird. I know: now there is a dependency, but this is T4 generation time, not compile time! And should it be good? Because the resulting POCO assembly is still completely immune.

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

Hope this helps

Alex

Answer 2

@Nick,

• To force recovery of POCO objects, you just need to right-click the main .tt file and select "Run Custom Tool." This will force it to update your POCO classes with updated changes to the .edmx model.
• Are there any problems with you, and right-click the model and select "Create Database from Model ..." even if you do not necessarily generate the database? Most likely, this will save you from your error "Error 11007 ...".
• I think this is equivalent to Code Behind. I do not know more than that.

Another thing to note is the link that Alex gave. As soon as I moved my main .tt file to another project, the file that was generated from the .Context.tt file will not compile because it lacks links to POCO files that were located in a different namespace (because I I wanted my ObjectContext to be in a different domain than my POCO files). I had to change the ".Context.tt" file to using Poco.Namespace (where Poco.Namespace is the namespace name in which the POCO files were created). This allowed me to compile my project.

Joel

Answer 3

For the EF5 + DbContext generator: it's easy to move your Name.Context.tt to another project. However, you will need to reference model classes. You can do it manually, but it will require you to change it every time the code is generated. You can also use the same namespace for both projects. It really will work, but I think it's a bad design. Another alternative is to modify the T4 template (Name.Context.tt).

Change this (line 43):

 using System; using System.Data.Entity; using System.Data.Entity.Infrastructure; <# if (container.FunctionImports.Any()) { #> 

For this:

 using System; using System.Data.Entity; using System.Data.Entity.Infrastructure; <# if (modelNamespace != codeNamespace) #> using <#=code.EscapeNamespace(modelNamespace)#>; <# if (container.FunctionImports.Any()) { #> 

This will check if the model namespace is different from your code namespace, if so, it will insert the necessary use to reference your model classes.

Answer 4

I encountered a serious error when using this approach in conjunction with projects and Dynamic Data controls. In essence, you will get an error.

"Failed to determine MetaTable. Failed to determine MetaTable for the data source" EntityDataSource1 "and cannot be determined by the request URL. Make sure the table is mapped to the data source or the data source is configured." with a valid context type and table name, or that the query is part of a registered DynamicDataRoute. "