This question is for Rockford Lhotka.
I was messaging with someone on this board who has worked with CSLA for several years. I had told them that I had taken the C# CSLA 2.0 framework and just finished modifying it to do the things I needed. They suggested that instead of modifying the existing framework that I create my own base objects that inherit from CSLA. That way when their is an update released I can point my objects at the new release and take immediate advantage of it. This leads me to an obvious question.
Is the backwards compatibility with previous versions of CSLA (within a language and major version) something I can expect?
The reason I am asking is because if I have to go back and modify every object I created previously because the new code broke it, then I shouldn't plan on doing code upgrades. Especially if you consider that I already have a working solution.
Backward compatibility is an important goal for me, but not an absolute requirement.
Each new release of the framework has changes (by definition) - bug fixes and/or enhancements.
If a bug fix requires a breaking change I will do so without too much remorse. It is a bug fix after all, and so is typically not optional, and the original behavior was broken regardless.
If an enhancement requires a breaking change, I will attempt to find alternative approaches that avoid the breaking change. Sometimes this means implementing some relatively nasty code inside the framework to get the enhancement, without breaking existing code.
In other cases I have opted to not implement enhancements to avoid breaking changes.
However, sometimes an enhancement is so compelling, and the breaking change (in my view) relatively minor, or easily overcome, and so I will implement a breaking change. I try to keep such events to major releases (2.0, 2.1, 3.0, etc).
Consider 2.1, where there are some potential breaking changes around validation rules. To minimize the impact, there is some nasty code in ValidationRules, supporting the old model alongside the new model. Even so, some breaks may occur - but I felt it was worth it due to the tremendous performance benefits of the change. Benefits that are so immediately compelling that I expect 2.1 to be well worth the upgrade effort for most applications.
In short, I take backward compatibility very seriously. But I can't promise never to break code, because there are sometimes good reasons (bugs or compelling enhancements) to break from compatibility.
You have to decide whether you are using CSLA as a base, starting from a snapshot in time, from which you'll evolve and maintain your own variant. Or whether you'll get enough value from ongoing bug fixes and enhancements to the core framework that it is worth tagging along for the ride.
I don't think there's any one-size-fits-all answer to that question.
As I've said before, and will say again, my primary goal in all this is to help people learn about architecture, framework design and related issues. The framework itself is a beneficial side-effect, that many people find immediately useful, and others use more as a source of ideas. And that's all good.
(at some point I need to blog about the fall of OpenVMS and DEC. part of the reason for the fall of the world's second largest computer maker to to the level of backwater-subsidiary-of-a-second-rate-PC-maker was due to their over-commitment to backward compatibility; to the point that they were so inflexible and slow-moving that the world simply passed them by...)
DeHaynes:
Thanks for responding so quickly. I am going to discuss it with my co-workers, but I think we are going to not go the upgrade route.
The changes from 2.0 to 2.1 are very compelling.
The work required to fix issues should be quite minimal.
I have been using CSLA for a few years now and the jump from 1.x to 2.1 will be difficult but not impossible. I plan on running them side-by-side for a while.
For 2.x I have implemented a layer of classes which inherit from each of Rocky's classes and then I override his methods or add my own. Then I derive all of my BOs from my layer. This makes upgrading a snap since I don't have to worry about propagating any hand changes I may have made to CSLA to the next version. Now the changes are isolated to my layer of code. Rocky has been *very* good about improving this extensibility area of CSLA.
In short - I think you should add the layer and do the upgrades. It is worth it in the long run.
Joe
Just one additional chiming in in support of 2.1. (Obviously it's your call, whether makes sense for your organization).
I'm pretty close to being done with my move to 2.1 - it's relatively painless.
Thanks for responding so quickly. I am going to discuss it with my co-workers, but I think we are going to not go the upgrade route.
From: DeHaynes [mailto:cslanet@lhotka.net]
Sent: Thursday, September 14, 2006 10:00 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Backwards Compatibility Question
Copyright (c) Marimer LLC