Lambert on Development

Rocky Lhotka recently announced another CSLA upgrade.  One of the features in this release is support for data annotations that work in both WinForms and SilverLight.  Yesterday, Rocky blogged about this implementation (Leveraging data annotation attributes in CSLA .NET).

While this feature is pretty cool all by itself, it’s easy to miss the real win here.  Looking back at the features that Rocky’s added to CSLA over the last few years, there’s a constant stream of technology-enabling features.  If you’ve built to this framework (and stayed reasonably current with new releases), you’ve gotten a free pass to take advantage of everything from remoting to WCF to data binding to SilverLight.

Here’s a news flash for you — that’s exactly why you get on board with a framework.  You don’t get this with design patterns, and you don’t get this with software factories.  Frankly, you don’t get this with a lot of other frameworks, either.

Well done, Rocky, and thanks.

Tweet This Post

October 6th, 2009 | Tags: .Net, Architecture, CSLA, framework | Category: .Net Development, CSLA | View Comments

Image via Wikipedia

A couple of years ago, I heard about a data-layer code generation tool called SubSonic.  At the time, there was a fair bit of confusion about how it was to be categorized – it wasn’t really an ORM, after all.  In fact, it was sort of a C# version of Ruby-On-Rails‘ ActiveRecord.  I played with it a bit, but I set it aside because I didn’t have any projects at the time that called for something like this.

Fast forward a couple years, and some things have changed.  SubSonic’s founder, Rob Conery, has been hired by Microsoft.  Somewhat surprisingly, this has not meant the end of SubSonic.  In fact, Rob’s working on a new release, and it’s shaping up to be really, really nice.  This is the first SubSonic release to come out with Linq support, and they look like they were made for one another.

When Rob announced the Subsonic 3 Preview 2 release, I grabbed it and took it for a quick spin.  If you’re going to try this release, Rob’s done a quick video that walks through a quick install and deployment, and I’d recommend watching it.  Installation couldn’t be easier – the readme file lists four simple steps, and if you do everything right, you’ll be up and running with scaffolding support for your database in less than five minutes (it takes less than one in the video).

What do you get for your effort?  SubSonic’s scaffolding support builds out classes for each table in your database, as well as helpers for all of your stored procs.  The syntax shifts since SubSonic’s earlier releases means that SubSonic 3 isn’t a true ActiveRecord implementation, but the syntax is very natural and (IMO) productive — it allows you to express database requests in a really compact form:  (example from Rob’s post)

Northwind.DB db = new DB();
var result = from p in db.Products
where p.CategoryID == 5
select p;

foreach (var item in result)
{
Console.WriteLine(item.ProductName);
}

Image by Tim Morgan via Flickr

There’s also support for LINQ queries, and you can batch queries so that multiple queries occur in one call to the database.  Even stored procs get an assist from SubSonic – procs are encapsulated into simple, type-safe function calls that return a reader for the results.  This is a big improvement over traditional data access layers where you’ll see tons of repeated code.

Part of the magic comes from the SubSonic assembly, which supplies database-related code that could cut a bunch of repeated code out of your projects all by itself.  That’s only part of the picture, though – there’s a set of generated files that gives you strongly-typed objects for each of your tables.  The code generation uses T4 templates – see this screencast on the Patterns & Practices site for more on T4.

While simple applications might make use of the generated partial classes as-is, more complex apps are going to want to extend and/or encapsulate these classes, and expose more complete business classes to callers.  There are a number of ways you could do this:

• Edit the generated code.  This is probably not an approach you’d want to take for a production app, but for a quick prototype, it could work well.  The problem with this approach is that your customizations are subject to breakage as the generated code changes.  If you can limit your changes to extensions (via partial classes), you might stand a chance here; otherwise, you’ll want to explore other options.
• Change the templates.  Since SubSonic is open-sourced, you have access to anything you might want to change.  Better yet, since the templates themselves are copied into your project, any changes you make there will be local to your project.  If your changes can be expressed in the T4 templates, this could be a really good option for you.
• Encapsulate the generated classes.  I’ve come to really like working with Rocky Lhotka’s CSLA Framework, but the data access parts of these classes freqently end up feeling a little more ponderous than I’d like.  SubSonic is just the thing to fix this – its syntax is crisp and compact, leaving me to focus on writing business code in my CSLA classes.  Personally, I like this model a lot – it builds on the strengths of both projects.

I’d also recommend checking out Rob’s webcast on using SubSonic as a REST handler.  There are some other interesting options if you’re trying to build a REST interface to your database (Astoria, WCF REST starter kit), but it’s a great demonstration of SubSonic’s ease-of-use.

Bear in mind that this is a preview release (before beta), so there are some rough edges.  I saw some code generation snafus where I had fields named the same as their tables, and there’s a problem with LINQ support that makes it tough to construct a LINQ query using the value of a variable rather than a reference to that variable.  You’re going to want to wait for a slightly more mature release before you start doing “real” work with 3.0, but this preview will give you a good indication of what’s to come.  There’s a lot here to like.

Tweet This Post

November 26th, 2008 | Tags: CSLA, LINQ, ORM, SubSonic | Category: .Net Development, CSLA | View Comments

Image by harold.lloyd (homologous) via Flickr

If you’re not comfortable using C# Generics in your code, be sure to check out this great article by Karl Seguin.  It’s an easy read, and it covers all the important ideas you’ll need to get your head wrapped around these things.

I’ve mentioned Generics a couple times on this blog – they’ve been a great resource to me.  I’ll admit – it took a little while for me to get comfortable with some of these ideas – especially multiple Generics, but since I’ve gained an appreciation for their capabilities, I find myself grabbing this tool early and often.

For me, the key to understanding Generics was to use them – as intensively as possible.  I used them in code I was writing from scratch, and then, when I started working with Rocky Lhotka’s CSLA Framework, I needed to work with them more.  His framework, in fact, makes very heavy use of Generics – to the extent that I could see someone being put off by the learning curve if they weren’t already comfortable with Generics.

Tweet This Post

November 21st, 2008 | Tags: C#, CSLA, Generics | Category: .Net Development, CSLA | View Comments

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.

Benefits

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.

Drawbacks

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:
http://www.primos.com.au/primos/Portals/0/Tech%20articles/CSLA%20WIIFM/What%20could%20CSLA%20do%20for%20me.html
Blog comments:
http://www.primos.com.au/primos/Portals/0/Tech%20articles/CSLA%20WIIFM/What%20could%20CSLA%20do%20for%20me.html
Blogger’s pros and cons:
http://claytonj.wordpress.com/2006/10/17/using-csla-as-an-application-framework/
InformIt article:
http://www.informit.com/articles/article.aspx?p=770361

Tweet This Post

July 2nd, 2008 | Tags: .Net, CSLA, framework, Rockford Lhotka, Rocky Lhotka | Category: .Net Development, CSLA, Software Reviews | View Comments