I need to upgrade our own framework which is based on (inherits, etc.) Csla but my issue arises from the fact that I cannot justify an upgrade of everything in one swoop.
I have winform and web apps currently and want to help move the business toward WPF and Silverlight and ideally open the doors to WP, iPad, etc. So Csla4.0 is a compelling move to make.
I have a lot of projects that encapsulate different parts of our own framework split out in a manner that folks can use features of our world with varying degrees of buy-in to our approaches/patterns/practices/etc. and mostly these don't need any upgrading.
However, I have a few core projects that inherit from Csla and add behaviours, etc. common to our world so that in the real application business layers very little plumbing has to be done (very much in the spirit of Csla itself). I can upgrade these pretty easily I think (from some investigations) but I'm wondering how I can continue to support the old and new worlds in the same client application.
If I wasn't concerned about supporting a single evolving client app moving elements from winform to wpf or simply adding new wpf elements I don't think I'd have any problem: I'd simply create new projects, share/link files, add references to new csla, etc. and build as the same assembly name and namespaces. Because they'd be deploy to different locations everything would work smoothly.
But, because I'll have scenarios where I have a single rich client application hosting winforms and wpf along side eachother this approach cannot work. So I essentially have to come up with new namespaces for the new stuff so there is no conflict with the old. This means that in every file that doesn't require any update work (the linked/shared files that make up 99% of the code) I have to change to put in an compiler directive to alter the namespace.
Surely there is some more clever way of achieving what I need - sharing Csla3.x and 4.x (and my own 3.x and 4.x framework) in a single client without major surgery throughout?
Hi,
In practice - you have 2 possible options.
1. 2 versions of CSLA:
You cannot load the same namespace.classname from 2 assemblies in onto the same AppDomain. So in order to use 2 versions of Csla:
2. Migrate to Csla4
Migrate your app to Csla 4 as quickly as possible and recode your Business+Authz rules.
I tried #1 when I migrated an app this summer but ended up doing #2.
Thanks to Andres I learned that I could add the old rules (common rules and couple of base classes) from 3.8.x and create extension methods to AddRules so that the old style of ValidationRules would be wrapped and added as Lambda rule in Csla 4. I haven't published or made these extensions available yet.
I did have to recode the Authz rules (or comment out) to make the app compile but I had my app up and running in very little time on Csla 4 and could then start working with the code and turn business rules into classes.
You should keep in mind the breaking changes from 3.8 to 4.x, here's some of the most important ones:
Thanks for taking the time out to reply Jonny. I would have thought a lot of folks are in a similar situation but then I read many of the early posts about 4.0 and got a different impression which surprised me. If I had being paying attention at the time I defintely would have been asking Rocky to think deeply about those who have invested heavily in earlier versions and would be in the winform-moving-to-wpf camp for some time (years probably). How can the multi (MULTI) million dollar products that have evolved over years manage this handicap.
What I definitely want to do is your suggestion 2 and I have (in my spare time) taken a crack at this. It has gone pretty well but then it'll be the devils in the detail that hurt me later when I find some developers following their own patterns using methods/property/combinations that I wouldn't have intended (I got this a lot in the move from 1.x to 2.x because, unlike Rocky, I didn't set out to write a framework but instead a set of encapsulated behaviours that could be reused and/or provide default behaviour).
Thank you so much for the list of important things to look out for in moving 3.x to 4.x. Weirdly, the rules engine is the one that will give me the most problems I reckon. I was a very early adopter of Clsa and, unfortunately now, had to extend the rules engine pretty extensively right from day 1. In later upgrades it still never matched the capabilities I needed/had so I have kept with my original. I definitely have to reinvestigate that whole area now and get with the Csla way of doing things if they provide all the capabilities I need.
However, I cannot get any backing for taking this route and, from experience, not having backing is just too risky in this environment. So I'm stuck with option 1. Looks like a regex find/replace throughout the entire code base is on the cards :(
Hi,
I expect you will find the new Rule engine to be very powerful and quite easy to use.
However, you can only attach rules to RegisteredProperties (ie, a PropertyInfo is
required) or object (when PropertyInfo is null) plus there is no more instance rules.
On the up side you can:
Which capabilities have you missed in the Csla rule engine?
Copyright (c) Marimer LLC