Is CSLA the right tool for a web-only environment?

Is CSLA the right tool for a web-only environment?

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


RockyRocks posted on Tuesday, July 05, 2011

I'm a big proponent of CSLA and have used it a lot. However, I've just moved company and I'm asking myself whether it is the right tool for the job here.

In my old place the ability to build a business layer and then make use of it with multiple UIs was something I used a lot. I am still a firm believer in a Windows app because you can deliver really usable stuff really fast in that environment. I've been told that at the new place everything must be delivered on the web.

Personally I think there is still a small case for using a WinForms or WPF UI for a subset of the functionality, but that's a debate for another day. For now, let's assume that we are web only.

In a web-only world, some of the stuff that CSLA offers is either not helpful, or less than ideal. Whoa! Bear with me here.

Here are (most of) the things that make CSLA beneficial (in general) in no particular order:

1. Teaches and encourages encapsulation and scope best practices (maximum encapsulation, minimum scope)
2. Data portal allows flexibility at time of deployment with only moderate architectural compromise
3. Rich validation engine for rich UIs
4. Strong data binding infrastructure
5. Authorisation supported/encouraged in business layer (more flexible/beneficial in CSLA 4.0?)
6. State tracking available with minimal code impact
7. N-level undo

In a web environment (WebForms or MVC - can't force use of browser plug-ins for our users, sadly), a number of these are much less useful.

1 is always good. No arguments there, but don't need CSLA to do this per-se.

2 remains useful, but does result in a compromise in the architecture.

1 and 2 make testing more difficult than it might be. In particular the use of shared methods doesn't sit well with abstracting to interfaces (because you can't abstract shared methods) and loose coupling. Testing is an area I very much struggle with; I want encapsulation of data access (so I don't like the factory data access methods stuff) but at the same time I want to be able to disconnect from the database for testing.

Having said that, the data access is for me the bit that is most likely to be wrong - I still prefer stored procs and changing the data layer and forgetting to change (or incorrectly changing) the data access in the objects is the most common mistake I make. Testing is probably easy enough with TypeMock, but it's expensive these days for a reasonable size team.

3 is much less useful on the web. Validation execution at the time of property update is less appropriate on the web because a page postback is effectively a batch operation. Therefore a one-time "validate all" approach might be better. At least some validation has to happen on the client and CSLA doesn't make reuse of validation rules easy. Use of Data Annotations or Enterprise Library Validation Application Block make this slightly easier as they support the idea of exposing rules externally; see http://www.codeproject.com/KB/validation/DataAnnotations.aspx for an example (not sure I recommend this, but anyway ...)

4 remains useful in WebForms, but less than other UIs. I personally don't make as much use of this as I would like in WebForms because I want to encode all output and sanitize all input and they are jobs for a layer above the business layer, in my opinion. No use at all in MVC - data binding is out of the window there as far as I can see.

5 is OK but it's not complex in old versions of CSLA, which isn't really doing much in and of itself in this respect. I know that authorisation has changed in 4.0 and that may make it more beneficial.

6 already exists in another framework that the new place uses (which is their own framework built from CSLA teachings methinks!)

7 is pretty much useless. No harm in it being there, but no help because of the way that people expect the UI to work on the web.

As you can see, I think the case for CSLA is somewhat weakened in a web-only environment. Don't get me wrong, there's not much here that STOPS you using CSLA. However, making use of a framework does have a price (such as keeping up with breaking changes, to name but one example) and you have to continually question what is the best thing to do to make sure you are doing the best you can in any situation.

What are other people's experiences in this respect? Do people continue to use CSLA despite these shortcomings (in the UI technologies?) How/where do people deal with encoding output and sanitizing input?

Cheers.

Andrew

Copyright (c) Marimer LLC