Question

I am looking for a good design pattern for rewriting the middle tier of a system incrementally while still maintaining its original database until enough of the system has been replaced that the old database can be swapped out in favour of the new.

So for example imagine you have a legacy system with Table A, and Table A has 100 coloumns thats maps to Object A that has 100 properties. You come along and decide that actually Object A can be split logically into 5 objects which in an ideal world would back onto 5 tables, but for the mean while has to persist into the original 100 column table. I’m looking for a way that a section of the middle tier can be swapped out and your new 5 objects swapped in but in the background it persists to the same database.

In reality we’ll not be swapping out the old middle tier but rather writing a new one that will slowly take hold, but for a period of time need to persist to the original db.

Any ideas?

Cheers.

Answer 1

I’ve decided to use NHibernate to take care of the mappings until we can start to replace the underlying database. So the object model will be properly normalised and svelte and using the mapping ability of NHibernate will map to the existing tables first before then swapping that mapping out for a new table mapping.