Upgrading from CSLA 1 to 4

Upgrading from CSLA 1 to 4

Old forum URL: forums.lhotka.net/forums/t/10279.aspx


khoff posted on Tuesday, April 19, 2011

Hi,

My company has been using CSLA 1 for years.  We're now looking at upgrading to CSLA 4 and were wondering what the best strategy would be for upgrading 200+ BOs.  We've tossed around ideas and their downsides, such as:

We understand this is a huge undertaking and that any solution will take quite a bit of work, both in code and in wrapping our heads around 3 generations of new features, requirements, and rules.  I've purchased the CSLA 4 eBook series to start absorbing all I can about it before we start the upgrade process to help us along the way.  We'd really appreciate whatever advice we can get.

Thanks,

Ken

tmg4340 replied on Tuesday, April 19, 2011

The first thing to realize is that this isn't an upgrade so much as a rewrite.  Pretty much the entire framework has changed in that time, and you very likely aren't going to be able to keep any semblance of your original structure, and probably hardly any of your code.  Especially if you're considering any of the new display technologies, or any of the asynchronous features...

I'd also say that your hosting option isn't likely to work either, unless you want to take your CSLA-1-era code and re-compile it into .NET 4.0.  Multiple versions of the .NET runtime cannot exist in the same AppDomain, so you'd have to hoist your code up to the new runtime version.  And even if you were to do that, all the structural changes in the framework are probably going to kill that idea.  And if that didn't do it, remember that you'll have to hoist the version-1 CSLA libraries as well, and you'll have a lot of work to do surrounding namespace collisions.  All this probably kills the parallel-library options too.

That leaves what sounds like the least palatable option.  I am assuming your "trunk" issues are because you're still modifying the existing app.  If you're going to do a rewrite, you're probably going to have to at least attempt to stop any sort of significant changes to the existing codebase.  I realize that the rewrite takes time, but if you are going to have any chance of doing it smoothly, you need to do your best to not have to work to a moving target.  Smile

HTH

- Scott

RockfordLhotka replied on Tuesday, April 19, 2011

If they've enhanced CSLA 1.53 to work in .NET 4 they can probably run both versions of CSLA in the same app. The trick is to rename the 1.53 namespaces to something like Csla153 (or something) and leave the CSLA 4 namespace root the same.

Then you can inherit from Csla153.BusinessBase or Csla.BusinessBase to get the version you want.

It should go without saying that all types in each object graph must be implemented with one version of CSLA.

khoff replied on Tuesday, April 19, 2011

Thanks for the replies.

Scott:  Yes, I'm aware that it is a rewrite, and that's why we were looking for advice on how best to handle it. We've actually moved our applications to .NET 3.5 with no problems, and the rest of the way to 4.0 doesn't seem too bad (ignoring warnings for obsolete/deprecated methods, which will be fixed shortly). That part of the parallel library idea doesn't seem to be the biggest issue...but that CSLA won't be able to exist side by side with an older version of itself, which Rocky just said should be possible.

Rocky:  Thanks for confirming that for me.  It seemed like a good way for us to manage this undertaking but even figuring out if it was possible could have taken too much time for us while we're just figuring out all the changes you've made from v1 to 4.

I suppose we will persue that route for a bit so we can start enjoying the benefits ASAP and take our time in the rest of the integration.  I may have more questions in the future as we start working out the implications and developing a plan.

Thanks again for the replies,

Ken

JCardina replied on Tuesday, April 19, 2011

Hi Ken, I tried to reply earlier but couldn't log in for some reason in firefox.

I am in the process of doing *exactly* what you are about to do, going from csla 1.x to 4.1 with a large commercial app with hundreds of business objects.

The old app is winform and asp.net  interfaces and we wanted to move to wpf / silverlight / html5 interfaces instead and generally modernize it all as well as add some much needed focus on comprehensive unit testing and opted for a complete rewrite.

I don't understand fully why you are even considering mixing versions as you say and I can't address that however I can address a complete rewrite as that's what we're doing now.

The process so far has been figuring out the basics of csla 4.x (and constantly having to remember to forget everything we know about csla 1.x) and then learning how to implement one of each of the core csla business object stereotypes we used in 1.x csla to 4.x csla.

Knowing about CSLA 1.x is a huge disadvantage and adds greatly to the learning curve.  The learning process proved to be *way* more time consuming than we thought at first.  Allocate *plenty* of time for this.

I am still not fully up to speed on all aspects of what I need to know but getting there; unfortunately Rocky hasn't finished some critical EBooks yet so you will need to consider the purchase of the older published book about CSLA 2008 even though it's v3.5 it's valuable because there is currently no comprehensive end to end information for 4.x and the changes from 3 to 4 are minor compared to 1.x to 4.x.

With all the changes it's easy to go down the wrong path and waste a lot of time and resources so I stongly suggest you do what I'm doing which is to pick a small sample of representative business objects of each of the major CSLA types in your 1.x csla project and port them to v4.x csla.

Pick the right objects so that they cover most of your cases of what you need but are simple enough to not bog you down too much and the right mix of objects so that you can make a simple UI for them in all the UI technologies you plan to implement.

The UI is a major consideration, don't look on it lightly even if you are not changing UI technologies because if your app is anything like ours you have a *lot* more code at the UI level than you should because some things just weren't possible with the old CSLA that are now easy to do at the business object level with the much more powerful business rules system.  You can now push nearly any UI code down to the business object level and this is a powerful feature of csla 4.x.

What I opted to do is preserve the existing database schema for the new version so I picked a representative business object from the original app for each major CSLA stereotype we use, (read only list, root object, etc etc).

I'm only starting in on the UI now, I used Unit tests for testing as I went along to implement the sample business objects.

In this way you can learn csla 4 from top to bottom using your business objects and your app's data so it's familiar and easier to learn and you avoid going down a wrong path while porting too much of your code at once.  You can test a portion of it as a finished app and ensure it will work as you wish from end to end (installation to upgrade) etc.

Finally you can then leverage the hand written code you wrote for each stereotype and write a converter application that can read your original class definition and emit a csla 4.x version.  This is doable and I've done it so far with all but one of the stereotypes I use.  I found it easiest to not bother with codedom techniques and simply read in the original source code, look for specific keywords with regex where necessary or simple string matching and then crank out the equivalent in csla 4.x to match what I came up with hand coding.  It helped tremendously that I was very uniform in my original classes.

It is *totally* worth taking the time to write a converter application.  In about  a day you can write / test and implement a converter for each stereotype and it will save you untold amounts of work and ensure everything is super consistent.  Even if it just converts parts of each class, anything that will save hand writing the code which is much more verbose in 4.x than it was in 1.x.

Of course you will still need to hand tweak those classes but you can convert 99% of the object over in my experience and all of that is the boring repetitive stuff.

 

bniemyjski replied on Wednesday, April 20, 2011

Hello,

Have you thought about using Code Generation to save time that it would take to rewrite in 4.0? Also, you speak of a conversion tool?? I've never come across something like this. Can you please explain in detail on what you needed to todo?

jwhook replied on Tuesday, December 13, 2011

I've just been reading your thorough response to the same question that we're now wrestling with ... moving from 1.x to 4.x.

I'm curious about how your rewrite progressed. Are you finished? As a result of your work, can you provide any kind of quantitative measure of effort to update the various elements of your application? Did you end up using any code generators?

I understand if you don't have time to answer, but any additional feedback you could supply would be appreciated.

- jim

Copyright (c) Marimer LLC