Our agency has been using CSLA for many years now. We have many shared assemblies, most of which are using 2.1.4. We found it to be fairly easy to upgrade to 3.8.3. However, there seem to be quite a few breaking changes in 4.0 that would require quite a bit of work on our part. I'm having a hard time convincing the group that we should commit the time to it.
For reasons that baffle me, I'm also having a hard time convincing the group that we should stay with CSLA at all, even though we've been very successful with it. The developers would rather re-invent the wheel I guess. I am hoping that if I can come up with a good plan to transition us to the newest version, I can put that sort of debate to rest as well.
Any advice you can give somebody in my position would be helpful. The whole issue of upgrading CSLA in general has been a pretty hot topic around here.
I believe migrating from 3.8.3 to 4.0 is a much easier upgrade then from 2.1.4 to 3.8.3. In any case upgrading to 4.0 would be much much easier than striking out building their own. I haven't upgrade any apps to 4.0 yet, but I have been writing a new app in 4.0 and the changes aren't to big. The biggest changes are with authorization and validation. But these changes are logical in nature, are powerful, and don't take much of a learning curve.
I think it is true that, assuming you are using 3.8 style coding structures, it is really not that hard to move to 4.
If you are still using 2.x coding structures (which you can in 3.8), then moving to 4 will be a little harder because you'll have to at least start using RegisterProperty() to register your properties. But even then, most of the old 2.x coding structures remain mostly intact - just tweaked to use the property info fields instead of string literals for property names.
It is true that all your ValidationRules.AddRule() and AuthorizationRules method calls are affected. But the changes are mechanical - it is just a bunch of repetative grunt work to make the changes. Not that I am saying this doesn't take some time - but it isn't like you have to rethink anything - it is just syntactic code changes.
For reasons that baffle me, I'm also having a hard time convincing the group that we should stay with CSLA at all, even though we've been very successful with it.
That kind of puzzles me as well - quite often.
It is not uncommon for me to end up talking to customers who have built, or are building, a framework for their app dev work. If they are using objects at all (which most are), their framework looks like CSLA from 2003 when it was extremely simple and didn't do all the stuff people really wanted it to do. In other words, they've identified the low-hanging fruit and solved the easy problems, but haven't gotten far enough to realize just how deep the rabbit hole really goes.
Last week I was working with a firm like this, and they needed to do some object mapping work. Fortunately I was able to point them at DataMapper and Csla.Reflection to get some ideas on how to solve their problem. But it in my mind this was a darkly humorous situation, since they were spending hours and hours of time reinventing something CSLA has been doing for years.
Copyright (c) Marimer LLC