Hi Guys,
I'm going to have a few cases where I want to add members to existing CSLA types (BrokenRulesCollection being one example). As I see it I have two decent ways of doings this:
1) Create my own MyCompany.CSLA assembly, put the new types in there and derive from the CSLA ones (using InternalsVisibleTo from the CSLA assembly to my assembly).
2) Modify CSLA directly.
The first solution seems like it'll give me the easiest upgrade path...BUT I still need to modify CSLA to hook in my custom classes at the appropriate points so its not perfect.
I imagine you've all tackled this sort of thing so I'm wondering how you've done it?
Thanks,
Colin Jack
I went the #2 route with the VS6 version. Boy oh boy did I go down the #2 route.
While handling new CSLA releases may seem like a 15 minute job with with the source control and merging functionality, if you're really planning on extensive modifications I don't think that is so easy once your modified version doesn't look so much like the original. Granted, there's so much more functionality in this version of CSLA and that risk is greately mitigated, but I for one am never going down that road again.
Having had a framework in place before "finding" CSLA, our approach was to use CSLA as a guide and toolset to improve our own framework - which we refer to as a hybrid-CSLA (on steroids) framework. With .NET 2.0, we went back to the drawing board and redesigned our framework from the ground-up but due to all of the customizations, extensions, etc. that we have in our framework we again chose a custom implementation.
With that in mind, the way we handle maintenance issues such as upgrades to the source code in CSLA (and other components we have access to the source code), is to maintain each version separately in our source control library. We do not merge versions. Then we can use a comparison tool such as BeyondCompare to diagnose what changes were made from version to version. Once identified, we can go through them and determine what may or may not need to be done to our own framework to leverage those changes.
We have found that this is rather painless once the framework is established on both sides. As mentioned in a previous post, most changes from one version to the next are going to be bug fixes (which may have already been caught) and/or enhancements to existing features that can be rolled into the framework in a similar manner if desired. Only when there is a major change, like going from 1.0 to 2.0 does this present a problem. But, since our framework needed retooling, it fit right in with our own plans (this time).
Because we aren't dependant upon the actual CSLA builds, we can chose when and if to implement the changes. This allows us to coincide this with scheduled upgrades and releases to our framework and better manage version creep that can occur with multiple projects using multiple versions of our framework refering multiple versions of CSLA and so on.
It has worked well for us thus far.
Copyright (c) Marimer LLC