Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers 2

up vote -1 down vote accepted

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.

share|improve this answer
    
You sound like you're assuming we have one large application or code-base that all database transactions run within. That is not the case. Most of the database transactions are native to their own projects. It would not be a shift - right now we have several stand-alone SQL-based back-ends. If we went with one mega-data-model then it would be combining all those small back-ends into one all-encompassing data model. Right now, the only possible break comes when the common code is touched and, even then, only when 2 developers are working on the exact same piece. –  user107775 Oct 24 '11 at 20:17
    
Branching and Merging only help with the initial check-in. Not once both packages are up the stream of the code migration and then the order needs to change to rush the second one pass the first. Sure, this can happen with any layout but it's rare currently because most developers are working within their own code-base. If we had one data model that everyone had to modify every time they made a database change then almost every package would have a version of the EFL .dll ... correct? –  user107775 Oct 24 '11 at 20:21
    
"Branching and Merging only help with the initial check-in". That may be true of systems like SourceSafe, but more sophisticated version control systems (like Subversion or Git) let you apply individual changes which happen in the code tree, from any time, anywhere. You're right -- I was assuming that there was one database. I would generally have one assembly per database, though the exact design decisions I'd make would be tailored to the exact situation. I'm sorry I couldn't give you a better answer... –  Dave Markle Oct 26 '11 at 11:37
add comment

My experience is: it's hell on earth.

We have a large core product that has many modules added to it. A given customer will have a core plus one or more modules, and any customer will have different set of modules to any other. Modules may make changes to the DB schema, typically to their own tables, but occasionally adding columns to to core tables too.

Previously this was easy, make your sql changes and ship along with installation instructions for each module. No problems whatsoever (unless, of course, it didn't get installed correctly, but that's a problem with anything).

When we moved to EF, it wasn't fun. Firstly, if you make changes to your DB, you change your local EF accordingly. You then have to rebuild all the modules and core that use that EF assembly - or you get errors, or worse, it fails to load a module completely. (ok, you can use the GAC and policy files, but they quickly addup and having a lot of the same dlls in the GAC stops it working, we found)

When it comes to roll out to test, you now have to build a EF assembly that views the DB the customer uses, and rebuild all the components - as you do have a versioning system - or none of them will load.

So we went from writing a text file with sql statements that was run in to whatever DB, to doing that plus updating many different EF dlls and making sure we installed them correctly, plus rebuilding a lot of our modules all the time. Perhaps we could have done it better with sub-EF dlls, but the core one is several Mb so we didn't feel like managing lots of these simultaneously on each customer site.

The savings could well be there in a silo-ed (you mean monolithic) application, but you still have to manage rebuilds as you change the DB schema (or you end up rolling out lots and lots of EF dlls). I might be tempted to do it again and try to get it right, but I think the old way was so simple and foolproof that I can't see why I'd bother. Having LINQ is nice, but writing old sql didn't exactly take all day to write.

share|improve this answer
    
Wow, thanks for your input. I suspected that there is something wrong with MSFT pushing out so many different ways of getting the data out of the database, but it still sounded cool. –  Job Jan 21 '12 at 17:07
    
MS has never got dB clients quite right, hence ODBC, RDO, ADO, ADO.NET, DAO, Jet/JRO, OLEDB, SQL2LINQ, ESQL/C, SQLXML, RDS, and now EF (of which there are at least 2 versions). –  gbjbaanb Mar 31 '12 at 13:51
    
I think the modularity aspect is an important one. Many nice quick demos of RAD technologies show trivial examples, but how do they stand up in the real world? If support for different DB vendors is not important and you stick to MS SQL Server, then you can leverage the schemas (from version 2005 onwards), which allow you to nicely separate and modularize a single DB, without any dependency issues or name clashes. I'm not sure if and how EF supports this though; we are using my own solution (which is, by the way, not a product of NIH) which supports migrations and modules per DB. –  Lucero Dec 28 '12 at 14:42
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.