I recently wrapped up development of a new application using Rocky Lhotka’s CSLA Framework, and I really liked it a lot. I think there’s a fair bit of mis-information and confusion circulating about this software, so while it’s all fresh in my memory, I threw together some notes on the things that worked well, and the ones that didn’t work so well, too.
Bear in mind that this material is offered at a high level – if you’re interested in really learning the framework, I’d encourage you to buy the book, download the framework, and dive in – the water’s fine.
One of the obvious benefits of this framework is that Rocky’s written a book to document the framework (multiple, if you count C# and VB variants, plus updates for new releases). The book does a pretty good job of walking you through the construction of the framework, explaining “why” as well as “how”. You can certainly learn the framework without reading the book, but if you like to do your tech learning out of a book, this one is a great read.
The CSLA framework takes a very OO approach to design. Where a lot of code-gen or “factory” approaches lay the entire model open and trust developers to do the right thing, CSLA enables and, in fact, encourages defensive programming with respect to the object model. You get to actually start using scoping modifiers to protect the inner workings of your classes, which is really nice. In my opinion, this encourages a much more robust object model because you can lock down ctors and setters where it makes sense.
This is feasible because you’re using the same objects everywhere you need them, regardless of physical tier, and this is actually one of the places where peoples’ eyes start to glaze over. Rocky actually does a great job of explaining this in his book, but a lot of people see examples with code from multiple logical layers in the same class file, and conclude that CSLA precludes the use of multiple physical tiers.
In fact, the framework actually makes n-tier development much easier and more flexible becuase it abstracts the protocol across layers. I can take the same code, in fact, and configure it to run all on one server (without incurring network traffic across tiers), or as a BL and DL connected via HTTP WS, WCF, or remoting. It really is just a config change to switch among these modes, which is pretty nice.
Some of this flexibility comes from the use of reflection in some spots, and that can put people off, but IMO, the benefits far outweigh the costs unless you’re trying to trade stocks or land the space shuttle. Comparing two applications developed for the same client and deployed into the same environment, the second app (using CSLA) is noticeable snappier, mainly because we’ve got fewer layers of junk to sift everything through, and because we’ve got a lot more control over how we optimize data access.
Data Binding is usually listed as one of the benefits of CSLA, but I’d broaden this to include support for all the MS interfaces that you’d want to support if you were starting from scratch. It does authentication and authorization, for instance, using the same MS interfaces you’d expect to find in use elsewhere. It does validation using the standard interface, and so on. The effect of all this is that stuff just *works*, instead of being a constant struggle to go build something whenever you want to interface with something new.
The CSLA objects have excellent support for “state”, including IsDirty-type infrastructure so the objects know when they need to be saved and what sort of CRUD operation that might be. They’re also capable of supporting n-level undo, though I haven’t needed that.
Finally, the object have good support for validation, including the ability to declaratively write business rules that drive “IsValid” and the ability to save your object. These rules can be reasonably sophisticated, since you’re writing them in code.
I’ve seen a few. First, it seems like I was constantly fighting FUD from people who didn’t know anything about the framework. As I mentioned earlier, there are a lot of misconceptions about this framework – maybe because of its “legacy” roots. I saw very little real merit in these arguments, however – they just don’t hold water when measured against facts.
Second, I saw a couple of places where I got caught building an object based on one base class, and it turned out later that I probably should have been using a different base. At that point, you don’t get any additional help with refactoring that doesn’t already come in the box. There are modeling or code-generation tools that can spew out CLSA code, and my experience here might have been different had I been using one of these. In any event, I was still way ahead using the framework.
Finally, I saw some places where validation didn’t cascade very elegantly down to complex children of parent objects. This isn’t the end of the world, since you can override anything by hand, but it would have been nice to get just a little more help from the framework on this one. At moments like these, it’s hard to resist the urge to just grab the CSLA source code and fix it. That’s an absolute last resort, of course, since it would make upgrades much more difficult.
In case you’re looking for more info on CSLA, I’ve pasted a few representative “community” opinions below – feel free to take a look at any or all of them. FWIW, Rocky tends to do a great job of explaining himself in forum posts, but I’ve yet to see him put together an effective “elevator speech” for CSLA, which is unfortunate.
CSLA Framework benefits:
Blogger’s pros and cons: