A little overview about what my group does …
I work in a development team in a fairly large insurance company. My group's responsibility consists mostly of building applications for our employees. Stuff like tracking systems, scheduling applications, contact directories, etc.
Of course we have a decent amount of "shared data" that all applications usually reference. Stuff like states, employees, and a slew of elements that pertain to our particular business (agents, lines of business, rating companies, etc). Currently, we have a set of common code that all the applications can leverage to retrieve most of that common data.
Most requests that we get in require either tweaks to the current database objects or creation of many new database objects. Our group is fairly small, but we still probably have 3-4 sets of database changes going through our Change Management System at any one given time and, depending on priority, some newer changes can leap-frog others on their way to production.
I understand all the benefits EFL brings but I also have a few concerns given our setup:
Since there is the element of shared data, it seems like it'd make sense to have one Data Model for our entire database (which contains all the objects for all the different applications). Is that a safe assumption? Or is it possible to build separate Data Models and have them interact with each other?
In the end, we want one class that is called "Employee" and we want that to be able to constant through any application so it seems like we either need to make one mega Data Model so that applications A-Z all have access to the Employee data and all reference the Employee class. Unless the class can sit in a GAC DLL and then each Data Model can reference …. or, like I asked, separate Data Models can interact with each other.
Then … if we do go with one mega data model, how difficult would it be to have different individuals making separate changes to that unified data model and then moving it up through a change management system?
I can see the benefits of using such a technology in a silo-ed application … especially one with minimal maintenance … but I'm having a hard time envisioning whether the time savings would still be there on a large scale with tons of different data model maintenance happening … all at the same time.
Any advice given would be greatly appreciated.
Best Answer
As far as versioning goes, I'll tell you that you already have this problem in a different form, though you might not know it. You have one database, but you have multiple projects accessing the data, correct? Essentially what's happening now is that since you are (probably) using SQL to access your database in each of your applications your project still compiles no matter what changes you've made to the database. Any truly breaking changes happen at runtime.
By adding an entity data model, you merely shift this break in your application to one that happens at compile-time. I guess my question back at you is "how are you versioning your database changes?" I would suggest you create a single entity data model, package it into an assembly, and make changes to it as you make changes to your database. Use branching and merging in your source control provider to manage how these changes actually happen in your development workflow. The newer versions of the Entity Framework are a lot better nowadays for managing merges than they used to be.