CODEWITHSUNDEEP
.netasp.net-mvcentity-framework
TheMentor
TheMentor

Reputation: 464

Separating POCO and Context file

So I am building .net mvc web app with n-layer architecture. I already have database so I would like to use EF6 feature to build Code First classes from existing database.

In the future I would like to use database migrations and also this feature for building code first classes from database again.

I really see this as a good and fast way to design database and POCOS. I would use Database migrations for simple cases like adding a column or changing column type. But I really like SQL Server Designer for building complex multiconnected tables with lots of relationships. So in that case I would design parts of database in SQL server and then use code first feature again to build all POCOs again with additional features that I build in SQL Server Designer.

The problem I have is that I would like to have my POCOs in seperate Entities class library and the Context file in my DAL library. Is it still possible to use Code First migrations in that situation? As I understand when enabling migrations you have to specify a class library on which you enable migrations.

I hope I describe the problem correctly.

UPDATE So here is what I tested now. I put generated POCOs in one class library and generated context in another. When trying to Enable Migrations in one class library or the other I got error The EntityFramework package is not installed on project 'DAL' and No context type was found in the assembly 'Entities'.

So I guess you have to have both together and having migrations in that class library. Its just funny to have POCOs in DAL or POCOs with Migrations in Entities class library

Upvotes: 1

Views: 366

Answers (1)

JotaBe
JotaBe

Reputation: 39025

You don't need to have POCOs and the context in the same project at all.

I usually have this projects:

  • Entities: a class library with all the POCOc
  • Data: a class library which references the Entities projects, and uses the EF NuGet package. In this project I also define the DbContext, and use the fluent API to configure it. And the migrations and configuration classes must also be in this project.

You have to run all the migrations stuff in the Data project. If you get errors stating EF is missing, or any other thing that's because you're doing something wrong, like missing parameters, running the Packagem Manager Console with the wrong project selected or something like that.

Please see this SO Q & A (at this moment is downvoted, but I warranty it's correct). There you have info on how to running the Migrations commands, seeing their help, and solving a common problem.

NOTE: mixing up POCO Migrations and reverse engineering is complicated. You should get used to create and configure relationships using the Fluent API. It's not difficult when you get used to it. In the meantime there is something that you can do: use somehting like "EntityFramework Reverse POCO Generator" VS Extension (by Simon Hughes). With this tool in your belt you can make a cahnge in the DB, run the T4 template, see what's generated and use that code in the "real DbContex". Leave the DB as it was, so that you don't interfere with migrations... or use -IgnoreChanges param, but that's harder to do

Upvotes: 2

Related Questions