We currently have 1 giant EDMX for our corporate database. It, along with all of the generated POCOs, are in a separate project (we’ll call it the EDMX project) which we pull in to any solution that uses the main database. In other words, any new application we develop uses this same EDMX project. Naturally, the EDMX project requires a reference to Entity Framework. But so do the main projects for each application. Thus, a given solution has 2 separate Entity Framework references – which could end up being completely different versions.
I inherited this setup and now have the opportunity to make some big changes. I have a suspicion we shouldn’t be using this one EDMX for multiple solutions, but am not 100% sure.
Questions
- Could having 2 different versions of Entity Framework in a given solution cause issues? It seems like it would, and we certainly do not want to constrain our newer applications to an old version of EF to work with the EDMX project which in turn works with older solutions.
- Are there any other reasons this would be bad?
Note: I have read similar questions about using 1 EDMX within the same solution (vs. splitting it up by schema, etc.), but my question is different because I am talking about using 1 EDMX for all solutions.
EDIT 10/16/14: So I pretty much have my first question answered. At least between Entity Framework 5 and Entity Framework 6, it does indeed cause issues. When my EDMX project has EF5 installed, and I upgrade my main project to EF6, many of my LINQ queries (inside the main project, referencing the generated-POCO classes inside the EDMX project) break. As I understand it, this has something to do with namespace changes. If there is a workaround to make the two versions work together, I haven’t found it.
My 2nd question still needs answered, however. Are there any other reasons it’d be bad to do, besides conflicting versions of Entity Framework? From a design perspective, does having 1 EDMX make sense?
Pros could be ease of updating (if a database table used by multiple projects changes, there is 1 place to update it). The obvious con is new projects being constrained to an old EF version until all other projects got updated. Any other issues that would crop up? Really just looking for some direction.
EDIT 10/17/14 I’ve accepted an answer but comments about your/your company’s usage of the EDMX would still be helpful/upvoted. The more perspective the better.
It depends.
The main thing I would focus on is “don’t repeat yourself”. If you have a bunch of applications using the same entities, it doesn’t make sense to spend a bunch of time and effort making and then maintaining the same thing over and over again. Worse, it can become a headache to keep all of them correct and in sync.
On the other hand, if you really have a bunch of different schemas that just happen to live in the same database (and don’t interact), then it can make sense to have multiple independent EDMX files.
I have seen both ways, and they worked well enough in their environments. But given the Entity Framework’s difficulties in playing nice with others, I would err towards putting all of a database into a single project, as it’s less work to “just use part of it” than “make it work with that other stuff too” should my guess be wrong about future usage.
1