DataLayer in Linq with different version of Data model

Question

Hi,

I wanted to ask the SO community about this problem in my project. I have a Silverlight App Project in SL 3.0, which at the moment has a classic design with a business layer and a data layer in Linq2SQL. The problem is that the Data model can be in different version with some little changes in between.

I have 2 solutions but neither of them seemed good :

1. Get rid of the Linq and put old stored procedures :

   • the good point if the data model changes i just have to change the stored procedures
   • the bad part is that my linq with dynamic filters would give me 30 stored procedures to change

2. Build one data layer for each version

   • the good point is that the model stays clean with unit test for non regression
   • the bad part is that I have to develop for each new version of the model

Is there a good pattern to watch for data layer accessibility?

Thanks and sorry for my poor English

Answer 1

I would suggest option 2, but make sure that both implementations implement the same interface. Have the type of data layer be stored in a configuration file and loaded at runtime by a factory class.

Answer 2

I would agree with C. Ross. One of the great things of using Linq (if not the only one) is that refreshing the model only takes a mouse click, whereas in the old days with Stored Procedures it could take hours to propagate a schema change through the various persistence and data layers.

The challenge is how to manage this in larger teams. You have to channel all schema changes through one person, I think, and manage the releasing of new versions tightly. I currently work on a project where I release a new model twice a week, and the overhead is very small.

Answer 3

Hey,

You could also use business objects to mitigate this some, making the LINQ 2 SQL objects DTO objects. Though more work (which can be reduced via T4 or codesmith), new objects in the business layer receive your LINQ to SQL object code, and your UI uses these DTO objects to bind data.

The trick then becomes that when you update, you need more code to then take the business object, query the LINQ object, and transfer the data from the business object to the LINQ object, and commit the changes. A little more work this way too.

But in this way, you can have multiple LINQ models, but only one business object, that either has all of the properties of all models, or has the properties that change in a dictionary collection or other mechanism (maybe a child object?).

There are ways to work around challenges like these.

HTH.