Rocky -
I'm trying to add the following comment to your article, but CoComment seems to be sticking (I see "
Stop trackShareTagsSending to coComment server ...", but it's stuck there). Anyway, here's the comment, fwiw:
Premise:
Best practices for CSLA use are to use the CSLA framework as-shipped. There are ample provisions for modifying behavior via overridden classes, methods, etc., so like most integrations, modification of the framework itself should be a last resort.
As long as the statement above doesn't hack anyone off too violently, I think you can move in the following direction while creating no actual damage to anyone, and a minimum of perceived damage.
Maintain the framework itself in C#. I developed exclusively in VB and VB.Net until about two years ago, so I understand the subtle chill that goes up the spine of VB developers, but I also believe that they tend to be a pretty pragmatic group, and they'll get over it.
Modification of the framework itself is defined to be an "experts only" activity, and as such, we're more comfortable with the idea that these experts have to be fluent in both VB.Net and C# if they're in a VB.Net shop. I don't think this is too far-fetched.
I also think this opens the door to a discussion of documentation (including the books). Some subset of the users of CSLA just want to use CSLA - they're never going to tweak any code, and that's perfectly appropriate. For these users, they're far better served in understanding implementation best practices, including how best to upgrade-proof their applications, vs. understanding the inner implementation of the framework code itself. Maybe at that point, the "how it's built" stuff turns into an e-book or something for the hard-core guys who what to step through the framework.
To summarize, the framework becomes a DLL with source code available, rather than source code that you can compile into a DLL.
As is always the case with such comments, this is just my opinion, so flame away....
Copyright (c) Marimer LLC