Reputation: 63
Apologies if this has already been answered, but after 2 hours of research I am yet to find a definitive answer to this issue. Hopefully asking will yield results.
I'm "somewhat better than beginner" with MVC and EF, but I do understand overall application architecture. You see, for even greater Separation of Concerns and future planned changes, I'd like to decouple my MVC project from Entity Framework. Here's what I have so far:
I've already created my Repository pattern (in the DataAccess project), and tested it using a separate UnitTest project. It all works.
Problem is, the consumer (the UnitTest project, in this case) still needs a nuget reference to Entity Framework (same with the MVC Web project). When I remove the EF reference from my Test project (and instead hard-code my connection string when passing it into my DataAccess project), I get this error:
No Entity Framework provider found for the ADO.NET provider with invariant name 'System.Data.SqlClient'. Make sure the provider is registered in the 'entityFramework' section of the application config file.
How can I design this so I can completely remove the Entity Framework reference from the Repository consumer (UnitTest or MVC Web projects)? I want to do everything via my Repository, without the MVC project knowing anything about my ORM technology.
Upvotes: 5
Views: 5401
Reputation: 11
The problem is that Visual Studio strips all references that are not used in the project. This solved the problem for me:
public DbContext()
:base()
{
var a = System.Data.Entity.SqlServer.SqlProviderServices.Instance;
}
Upvotes: 1
Reputation: 291
You could try accessing your services via a Web API, which acts as a buffer to the Data Access Layer(s) and deals in View Models passed back and forth as anonymous JSON objects. Your front end (website) can then be totally isolated from the details behind the API and just act as a client to it. Angular JS / Angular (2) lend themselves well to this approach as I'm sure many other client side technologies do.
Upvotes: 0
Reputation: 2266
Even after removing NuGet package you might be having residual props in your configs (packages and/or web) related with EF. It's also worth checking your csproj file as well. The issue that you are having is the lack of a line like this in your config.
<entityFramework>
...
<providers>
<provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
</providers>
</entityFramework>
That being said, this still shows that your project is actually bound to EF afaik.
Upvotes: 0
Reputation: 239460
This is a bit misguided. First, the reason a reference to Entity Framework is required is because you're leaking code from that library into your MVC project. The only way to avoid a reference is to 100% segregate the code. Which is potentially possible, but not easy by any stretch. However, that's not important anyways. Having a reference to Entity Framework is meaningless. The important part of N-tier design is segregating distinct functionality, not necessarily references. If your DAL depends on EF and your MVC project depends on your DAL, then you have an inherent dependency on EF anyways.
Upvotes: 3