Suggestion needed on CSLA route given Framework version limitations

Suggestion needed on CSLA route given Framework version limitations

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


TSF posted on Wednesday, August 04, 2010

A few of my co-workers and I have been reading about (and experimenting with) CSLA over the past year, and have recently been given the opportunity by mgmt to officially go the CSLA route for future projects.  Among a number of questions we now face, one stands out which we're not sure how to address: which version of CSLA do we target when building our business objects?  Here's our scenario:

Our company has a considerable number of WinXP SP1 & SP2 machines (40% or so) with the remaining being WinXP SP3 and a few new Win 7 machines.  Per Micrsoft, the .NET 4.0 framework only runs on WinXP SP3 or higher, while the 3.0/3.5 framework runs on SP2 or higher.

I have concern about which version of CSLA we'll target when building our business objects, particularly from a binding support standpoint in WPF.

While we may need to fallback to WinForms 2.0 for apps that go to everyone in the company (in order to support SP1 machines), we'll also have projects that will target a subset of users that are guaranteed to have WinXP SP3 or Win 7, which means we'd like to use the .NET 4.0 Framework for those cases.

Are there any recommendations in this scenario regarding how we should go about building our objects?  Is it reasonable to assume that if we build out, say, a vendor object, that we could maintain two versions without too many coding differences between them?  In other words, one to support .NET 2.0 clients, another to support .NET 3.5 or 4.0 clients? Would an object built against CSLA 3.0.5 be consumable in a WPF (3.5 or 4.0 framework) app?

Thanks.

TF

dlambert replied on Wednesday, August 04, 2010

Is a web client a possibility?  This might let you run .Net 4.0 on the web server, at least.

TSF replied on Wednesday, August 04, 2010

In a few cases it could be, but we've got a lot of existing WinForms apps that we'll be migrating to using CSLA.  In addition, we've got a lot of VB6 apps that we'll be migrating to .NET via the Interop Forms Toolkit, and their requirements dictate a WinForms (or WPF, eventually) scenario.

tmg4340 replied on Wednesday, August 04, 2010

Unfortunately, I don't think that maintaining multiple versions of your BO within a single codebase will be particularly effective or easy.  If you have to slide all the way back to .NET 2.0, you're going to be going back several versions of CSLA.  There have been major changes in property management, business-rule/authorization implementation, and other areas that aren't really backwards compatible - either because they use non-2.0-supported functionality, or because they were never back-ported into prior versions.  Some backwards compatibility is maintained, but likely not enough for you to be able to maintain the same BO code and link/re-compile against different .NET targets/CSLA versions.

Additionally, there are significant differences in the data-binding infrastructure between WinForms and WPF, and different collection base classes that have to be used to get all the functionality.  WinForms works off a BindlingList, while WPF works best off an ObservableCollection.  WPF partially supports BindingList, but not completely - which is why you see two sets of collection base classes in CSLA 4.  Rocky has essentially deprecated WinForms in CSLA 4.

If you want to use the "lowest common denominator" approach (find the version of CSLA that is supported in every environment), you'll have to go to the download page and find the latest 2.0 version.  I know there's been some work by the community to back-port some features of more-current versions, but you still won't get everything.  Otherwise, you're likely looking at multiple codebases to maintain.

HTH

- Scott

RockfordLhotka replied on Wednesday, August 04, 2010

If you need to use .NET 2.0, you should consider using the N2 version of CSLA. That's basically CSLA 3.7 that can run on .NET 2 (with some helper components that provide some .NET 3.5 features to .NET 2).

Otherwise you'd have to use CSLA 3.0.5, which pre-dates the new property declaration syntax. And that's a pretty big deal, since moving from 3.0 to 3.8 or 4 would require a lot of work (at least if you want to use the newer features). That property declaration syntax was a big, and important, change.

On the other hand, if you can at least target .NET 3.5 SP1, then you can use CSLA 3.8, which is pretty good. It is true that CSLA 4 replaces the business/authorization rules mechanism, but for the most part 3.8 code is quite similar to CSLA 4 code outside the rules area.

For validation rules, at least, if you can use DataAnnotations attributes, those carry forward from 3.8 to 4 - so that can help minimize the upgrade effort to some degree.

All that said - it is also the case that the "old style" 3.0 code (for the most part) still works without change in 3.8. You can't use all the 3.8 features, but the older style code generally continues to function. But to get to CSLA 4 you really do need to start at least using RegisterProperty - which means reworking the old style property declarations.

TSF replied on Wednesday, August 04, 2010

Thanks to both of you for your answers...I'lll have to think through those things with the other developers.  Until then, can I ask if anyone has any experience running a .NET 3.5sp1/4.0 app on an WinXP SP1 or SP2 machine?  I know MS doesn't support it, but I have been able to install the .NET 4.0 famework on an SP2 machine.  I just don't know what kind of issues I might run into if I used .NET 4.0 / CSLA 4 on an SP1 or SP2 machine.

Thanks.

asinc replied on Friday, August 06, 2010

Given all of the complexity in your environment perhaps you should seriously evaluate moving this to Silverlight? Then you can go 4.0 for everything and get all of the other related benefits of SL?

Copyright (c) Marimer LLC