1

I recently started to get into EntityFramework in order to map my model automatically into a MySql database. So I read some tutorials and started tests to validate them. Everything works fine, as far as I only have one project. If I separate the solution some problems arise. In order to demonstrate this, I set up a console project (lets call it A)with EF6.1 that saves all my data to the database. Everything works fine. If I now create a second console project (lets call it B) and and use the DbContext through a IRepository-Wrapper (from A) some problems occur:

  1. First of all, I have to put my config data for the database and EF config into the App.config of project B. I don't like this, but I can live with this.
  2. Furthermore the application compiles, but throws a exception, as long as I don't reference EntityFramework.SqlServer in project B.

In order to separate the concerns I don't want project B be to know that the data is stored via EF in a database. Or to give a real world example I don't want that my WPF Gui knows, that the data came from a database.

Is there a workaround for these problems? Did I miss something, or do I have to live with that problem when using EF?

0xBADF00D
  • 890
  • 1
  • 11
  • 23
  • You would get the same problem with any framework for retrieving data from a database directly. In order to have that level of separation you would have to create some kind of service layer with Web API, WCF or similar. In a Silverlight APP you would use WCF RIA services for example. – Ben Robinson Oct 22 '14 at 15:55

1 Answers1

0

For the first problem, you're not forced to put your connection string in the assembly's config file. You can use whatever you like (your own config/ini file, the registry, etc.), and then pass the connection string to the DbContext(connectionString) constructor.

As for the second issue, this seems to depend on how you are abstracting the database. If it is a complete abstraction, then it shouldn't leak any dependencies on EntityFramework.SqlServer. On the other hand, Entity Framework itself already follows the repository design pattern, so I'm not so sure if you need to add another layer on top of it. If you do want to continue with creating a database abstraction layer, consider putting it in a third library project that the other user-facing application projects reference.

Jonathan Amend
  • 11,785
  • 3
  • 20
  • 27
  • The reason for the separation is, I don't now if I want to use a database in the future. Maybe in future I use some XML file or a web service. Furthermore I already separated these. My database stuff is in project A and that is access via project B by calling a factory that returns a IRepository object. While compiling everything works fine, but during run-time I get exception saying SqlClient could not be loaded and I should make sure that the assembly is available during run-time. If I add the reference to EntityFramework.SqlServer, everything works fine. – 0xBADF00D Oct 22 '14 at 16:26
  • I recently noticed, that the Debug folder of A contains the library EntityFramework.SqlServer as expected, but project B (that referenced A) does not. But it contains all the other libraries references my A (MySqlData.dll, MySql.Data.Enitiy.EF.dll and EnityFramework.dll). Maybe there is another problem going on here. – 0xBADF00D Oct 22 '14 at 16:32
  • The second problem actually seems to be a bug in Visual Stuido as decribed and solved [here](http://stackoverflow.com/questions/1132243/msbuild-doesnt-copy-references-dlls-if-using-project-dependencies-in-solution). But I don't get the first problem solved. I used a custom DbConfiguration as described [here](http://dev.mysql.com/doc/connectors/en/connector-net-entityframework60.html), but it complains a DbConnectionFactory could not be found. Seem quite similar to the problem discussed [here](http://stackoverflow.com/questions/23219981/windows-service-ef-mysql-without-app-config). – 0xBADF00D Oct 23 '14 at 15:27