Opinions on dividing up a single entity framework layer in source control
-
This is probably the first question I have asked on CP, so please be gentle :), also my terminology might be a bit all over the place. I admit I am pretty much a beginner as far as entity framework and architecture are concerned. I am in a bit of quagmire, I have inherited several applications that rely on one database and that database has one datacontext project which all these applications plug into. Currently we are using TFS and each of these .Net applications have a project reference to this data context project, which is fine if you do not need to branch out and if it is a single programmer outfit. Now I want to implement a better release strategy after a few D-Days and issues with half finished code (not caused by me). I want to go with the Gitflow strategy where I have three types of branches, a release (golden) branch, a trunk development branch and a day to day development branch. Now with several projects all tied together by a single datacontext project it is painful creating new branches, merging up, as it is huge and we lose track of changes. I agree there is very tight coupling and this needs to be reduced, I want to come up with a sane way of splitting the context and the applications into single entities. I agree what ever I do it will be time consuming but I would love a few opinions and experiences on people who have battled with this issue. Thanks for reading,
-
This is probably the first question I have asked on CP, so please be gentle :), also my terminology might be a bit all over the place. I admit I am pretty much a beginner as far as entity framework and architecture are concerned. I am in a bit of quagmire, I have inherited several applications that rely on one database and that database has one datacontext project which all these applications plug into. Currently we are using TFS and each of these .Net applications have a project reference to this data context project, which is fine if you do not need to branch out and if it is a single programmer outfit. Now I want to implement a better release strategy after a few D-Days and issues with half finished code (not caused by me). I want to go with the Gitflow strategy where I have three types of branches, a release (golden) branch, a trunk development branch and a day to day development branch. Now with several projects all tied together by a single datacontext project it is painful creating new branches, merging up, as it is huge and we lose track of changes. I agree there is very tight coupling and this needs to be reduced, I want to come up with a sane way of splitting the context and the applications into single entities. I agree what ever I do it will be time consuming but I would love a few opinions and experiences on people who have battled with this issue. Thanks for reading,
A (current release) Entity Framework app is not limited to one "DbContext" per database (if that's what you're referring too). The "entity class definitions" are what's "common" here; a given DbContext is simply a class that identifies the entities too be used in a given "context" (i.e. program / app). I can have 3 tables: A, B and C. One context can include tables A, B and C; another just B and C ... like a "view". So; I don't see DbContext classes as limiting your ability to move forward.
-
A (current release) Entity Framework app is not limited to one "DbContext" per database (if that's what you're referring too). The "entity class definitions" are what's "common" here; a given DbContext is simply a class that identifies the entities too be used in a given "context" (i.e. program / app). I can have 3 tables: A, B and C. One context can include tables A, B and C; another just B and C ... like a "view". So; I don't see DbContext classes as limiting your ability to move forward.
Thanks for clearing that up for me, in that case I shall have multiple DbContexts referring to the same table but only sections I need for different applications. Thanks again,
-
Thanks for clearing that up for me, in that case I shall have multiple DbContexts referring to the same table but only sections I need for different applications. Thanks again,
-
This is probably the first question I have asked on CP, so please be gentle :), also my terminology might be a bit all over the place. I admit I am pretty much a beginner as far as entity framework and architecture are concerned. I am in a bit of quagmire, I have inherited several applications that rely on one database and that database has one datacontext project which all these applications plug into. Currently we are using TFS and each of these .Net applications have a project reference to this data context project, which is fine if you do not need to branch out and if it is a single programmer outfit. Now I want to implement a better release strategy after a few D-Days and issues with half finished code (not caused by me). I want to go with the Gitflow strategy where I have three types of branches, a release (golden) branch, a trunk development branch and a day to day development branch. Now with several projects all tied together by a single datacontext project it is painful creating new branches, merging up, as it is huge and we lose track of changes. I agree there is very tight coupling and this needs to be reduced, I want to come up with a sane way of splitting the context and the applications into single entities. I agree what ever I do it will be time consuming but I would love a few opinions and experiences on people who have battled with this issue. Thanks for reading,
git (regardless of process on top of it) is not well suited for handling multiple deliverables unless in fact those deliverables are real deliverables. So for example if your company has a logging library that has its own sprints, its own requirements, schedule and delivered versions then that is a deliverable library. And the applications in the rest of the company would use a delivered version of that library. With git that would then exist in its own repository. In comparison what often happens is that there are several large entities which compose a single delivered application/system. A change in one part of the system invariably requires a change in another one or even several entities. All entities are manage in one sprint and a release involves all of the entities at the same time. I am guessing you have the second. And it is unlikely you will ever have the first. Possible just not likely. The only way to really ease the burden with the second is to very carefully manage dependencies. And that is not something that technology does - it requires a person. Thus if you add a new feature then the back end code is finished and, hopefully if possible, QAd, before the front end is even started. Obviously this is a probably when modifying existing code but then you can add new functionality as different endpoints and denigrate the old endpoints for removal in a future sprint. Again this is a manual process.
darkliahos wrote:
I would love a few opinions and experiences on people who have battled with this issue.
A good a conscientious project manager can help a lot. There are not a lot of those however.