01 October 2004

It seems that TheServerSide.net has a debate going this week about

O/R Mapping. As part of the discussion, one of the invited debaters made the following comment about CSLA .NET:

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

“…everyone just "loves" CSLA, afterall its got every feature imaginable, was created by one of the best "experts", is the subject of books and user groups -- and yes there are code gen templates for it. Now don't get me wrong, I think Rocky is a great speaker and teacher (and great in person too -- I have met him), but I think he would agree that CSLA is an example for teaching how to do something and should not really be the expected to be perfect out-of-the-box -- and its not. I've personally seen a project spend way too much time and effort doing things because they chose this route -- they had to constantly go and add/remove/modify pieces to their chosen framework -- and I've heard many others that have similar problems.” (link) -

Paul Wilson

  It is not the most professionally phrased comment, but this gentleman has previously made similar comments in other forums as well, so I thought I should provide an answer.   I think it is important to note up front that Mr. Wilson

sells an O/R Mapper tool, and so has some bias. It is also important to note that I have written numerous books on distributed object-oriented architecture, and so I have some bias.

  CSLA .NET is intended to be a learning or teaching vehicle. It is often also useful in its own right as a development framework. Different people write different types of books. For instance, Martin Fowler’s excellent

Patterns of Enterprise Application Architecture came out at about the same time as my .NET Business Objects book. In many ways he and I are targeting the same demographic, but in different ways. Fowler’s book stays at a more abstract, conceptual level and teaches from there. My book is more pragmatic and applied, teaching from there.

  As an aside, I find it wonderful how some of the patterns in Fowler’s book can be found in CSLA .NET. I think this goes to show the power of the design pattern concept – how patterns emerge in the wild and are documented to help provide a more common language we can all use in future discussions.   But back to books. We need books that give us broad theory and concepts. We also need reference-oriented books that give us basic usage of .NET, C# and VB. And we need books that try to span the gulf between the two. This is where I’ve tried to live for the most part – between the theory and reference content. To do this is challenging, and requires that the theory be distilled down into something concrete, but yet rich enough that it isn’t just more reference material.   The way I’ve chosen to do this is to pick a way of creating distributed object-oriented applications. Are there other ways? Oh yeah, tons. Are some of them good? Absolutely! Are some of them bad? Again, absolutely. Is CSLA .NET good? It depends.   Certainly I think CSLA .NET and the rest of the content in my business objects books are good for learning how to apply a lot of theory into a complex problem space. I think that many readers use ideas and concepts from my books in conjunction with ideas from Fowler’s books,

the GoF book and lots of other sources.

  A side-effect of writing a book on applied theory is that the theory does actually get applied. This means that the book includes a pretty functional framework that can help build distributed object-oriented applications. This framework, CSLA .NET, can be useful as-is in some scenarios. There’s a

vibrant online forum for discussion of my books and CSLA .NET where you can find numerous examples where people have applied the framework to help solve their problems.

  Many of those people have also modified the framework to better suit their needs or requirements. This is nothing but good. In several cases, modifications made by readers of the books have been applied back into the framework, which is why the framework is currently at version 1.4, where the book described version 1.0.   Does CSLA .NET fit every need? Of course not. No tool meets every need.   It is particularly good at creating performant, scalable line-of-business systems that involve a lot of data entry and business rules and relationships. It supports people who build a good object-oriented business entity model, because it provides for virtually unlimited flexibility in translating the object data to arbitrary (relational and/or non-relational) persistence targets (databases, etc).   It is not particularly good at creating reporting systems, large batch processing systems or systems that are very data-centric and have little business logic. There’s also a cost to the data mapping flexibility I mentioned as a benefit – because with that flexibility comes more work on the developer. If you have either a non-complex data source or you are willing to tie your object model to your data model then CSLA .NET isn’t ideal because it requires that you do more work. If you want your object model to mirror your data model then use a DataSet, that’s what it is designed for.   But the real thing to keep in mind, above all else, is this: there is a set of functionality that must exist to build distributed object-oriented enterprise applications. This includes data persistence, UI design support, business logic, organization of layers and tiers, state management and more.   The issues that I address in my business objects books and CSLA .NET are addressed in every enterprise application. Whether formally or informally, whether through reusable or ad-hoc implementations – everything I address happens in every enterprise app. (And a whole lot more things I don't address are in every enterprise app!!)   The idea that CSLA .NET has “got every feature imaginable” seems to imply that it has extra stuff you don’t need. The fact is that you will address every issue it covers one way or another, plus numerous other issues. You might address them differently that I did, and that’s great. But you will address them.   You can address them in an ad-hoc manner in each app you write. You can address them through a framework, or you can address them through tools. You might address them through a combination of the above.   But I’ll say this: the ad-hoc approach is poor. You should opt for a solution that provides reuse and consistency. There are numerous ways to do this, CSLA .NET is one and I imagine that Mr. Wilson’s O/R mapper tool is another. And there are various commercial frameworks and other O/R mappers out there as well. You have a lot of choices – which is indicative that this is a healthy segment of our industry.   The fact is that at some point you need to make hard decisions within your organization that move from the theory of design patterns and architecture down to the practical and pragmatic level of code, and you only want to do that once. It is expensive, and it does nothing to solve your actual business needs. All this code that does data persistence, layering, tiering, data binding and whatever else is just plumbing. It is necessary, it is costly, it is time-consuming, and it provides no direct business value.   And be warned – if you buy or otherwise acquire a framework or tool set (CSLA .NET, O/R mappers, whatever) you will almost certainly need to modify, extend, add or remove bits and pieces to make it fit your needs. If you do this by buying a black-box component of any sort, you’ll end up extending or modifying around the component, while if you acquire one that includes code you may opt to make the changes inside or outside the component.   Obviously you can acquire a component that does less work for you – something targeted at a narrow task. In that case you might not need to modify it, but you must face up to the fact that you will need to write all the other stuff that it doesn’t do. It isn’t like you can escape the requirement for all this functionality. Every app has it, whether you do it in a reusable form or not is up to you!   So when it comes to frameworks, O/R mappers and all this other plumbing: do it once – build it, buy it, cobble together products to do it. Whatever suits your fancy.   Then get on with building business apps and providing actual value to your organization.