I am looking for suggestions, recommendations, etc. for refactoring an existing production application to work with CSLA. This will be my first application where I am bringing CSLA into an existing product. My principal concern is breaking compatibility with the existing version on the market. I believe the impact can be mitigated for everything except the back-end database. After all, what goes on under the hood doesn't really matter. But, I'm leaning towards some schema changes (such as implementing guid primary keys) but am uneasy about the best approach as the changes will have to be deployed in a way that allows existing customers to upgrade easily.
Any thoughts?
You could leave the database schema alone unless there is a real need for Guids, but if you want to go that route it's just a case of writing a good upgrade installation script or project.
You might find that you end up modifying some of the select stored procedures anyway if you like the CSLA way of having the Parent object fetch it's children in the same Select stored procedure.
RikGarner:
I know it will be tons of work, but have you considered building a test harness around the exisiting code base before you touch anything? It would give you much more confidence that making changes doesn't break the application.
I agree with Rik, it will be a lot of work but this makes the transition alot "Safer"
We're in the middle of doing this exact same thing, complicated by the original product being a C++ ODBC/DAO application.
We had some fairly unique requirements -- our users tinker with the database schema by changing field sizes, so hard-coded field lengths were out. We also have a facility for adding both custom fields and validation tables for them to the application. We also support 3 different back-ends, Oracle, SQL Server, and Access.
To make a long story short, we chose an Object Relational Mapper for the low-level DAL -- it generates dynamic SQL for all 3 database types and was easily modified to support registering of fields not present in the initial schema.
As far as CSLA is concerned, after some false-starts it is proving to be straightforward.
We've found that any business transaction method that we previous had can almost be translated to a CSLA business object (BO) by rote. Just convert your methods to BO's and do the "interesting" work when the BO is "saved".
Copyright (c) Marimer LLC