17

I have three projects (WCF projects, not clients), I have one database for all, now how will I use EF with this? should I make a fourth project which will have the db context and the entities and then add a reference to it in all three projects? or should I just have a separate context for each project and just add the tables i need for each project? some of the table are really used everywhere. so what's the best solution for this?

Another question: should I expose the EF db context in the separate project so other projects can access it? something like:

 MySeparateProject myPr = new MySeparateProject();
 using (var db = new myPr.DBContext())
 {
     // do stuff with entities
     db.SaveChanges();
 }

2 Answers2

22

I think the cleanest thing to do is create a data access project (class library) that contains just your models and db context, and reference that from all of your other projects.

Some people will say that you should make one class library with just the models, and then have yet another that has the DbContext, and the have repository classes, and then.... I feel this is overkill for the majority of projects. Having the models and context in one place just makes it really easy to keep all the dependent projects consistently in sync when it comes to data access.

Here's a typical project structure for me:

enter image description here

Here, Squelch.Data contains all of my models and db contexts, Squelch.Core contains core business logic, and my two "applications" (Squelch.Portal ad CdrImport), and the various test cases, all reference these base class libraries.

Myk Willis
  • 12,306
  • 4
  • 45
  • 62
  • Well actually for a finer tuning, without overkilling it (and oversweatting on Migrations if you gonna go with database first) would be a DAL with contextes and Entity models and then a Models library for your BLLs an Application layer to use. – Shockwaver Nov 16 '17 at 08:50
  • Would a data-access Solution work alright? And then include it in as a git submodule perhaps. – Andrew Oct 13 '19 at 12:58
3

I would create a separate data access project. It is good practice to separate your data layer out anyhow. Depending on the nature of the project and how you want to test it, you may want to take a look at something like the repository pattern (though there is debate about its value with EF).

http://msdn.microsoft.com/en-us/library/ff649690.aspx

Jason
  • 651
  • 5
  • 10
  • Actually this what was in my head, EF and repository pattern is kinds double work... –  Jun 15 '13 at 04:43