Our application provides an user interface to another system with a data schema that is not within our control. Our application uses CSLA to create business objects to allow editing of the data in the third party system. However, as the third party data schema evolves we have to evolve with it. However, at any given time our customers can have any version of the third party system with a different data schema. Therefore, our application needs to be able to adjust to whatever supported version of the schema that the customer happens to have.
We have looked at possibly using the Strategy Pattern to solve this. Essentially having a base class that supports the lowest version of the data schema and then having derived classes to support each subsequent version. In turn, we would have a factory that returned the class that corresponded to the current version of the data schema. However, we are concerned with the possibility of a long and confusing inheritance chain this may cause. Is there a better way to solve this problem? Possibly with composition instead of inheritance?
I found this post that outlines a possible way to handle this
http://securesoftwaredev.com/2009/05/31/supporting-multiple-versions-of-a-data-model/
I am not sure if this approach would work for us but wanted to get some other ideas before I implementing anything.
CSLA .NET makes it easy to separate your data access logic (DAL) from the rest of your application.
Because you should use CSLA to create business objects that map to the problem domain, not the database shape, your DAL should be concerned with accessing the database and mapping the data into the business objects as necessary.
If you have two different database schemas then you’ll probably have two DAL implementations, both of which access the databases and map the data into the exactly same business types.
The Using CSLA 4: Data Access ebook covers this pretty extensively, and the ProjectTracker sample (version 4.0 and higher) uses an abstract DAL that demonstrates the concept as well.