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

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

Old forum URL:

RockyRocks posted on Friday, July 15, 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. I've been told that at the new place everything must be delivered on the web. Note that by web delivery I am talking about WebForms or MVC - sadly Silverlight can't be used.

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.

Some of the issues are:


The validation model is less useful on the web. Validation rule execution at the time of each 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 more efficient. 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 for an example (not sure I recommend this, but anyway ...)

Data Binding

The strong data binding support could remain useful in WebForms, but less useful than it is for richer UIs. I personally don't make as much use of binding 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. Data binding is no use at all in MVC - it doesn't really fit with the underlying concepts as far as I can see.

N-level undo

N-level undo 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.

You still get:

Encapsulation and scope best practices
Data portal is there in case it is required
Some assistance with centralisation of authorisation rules
State tracking with minimal code impact

I think the case for CSLA is weaker in a web-only environment. Don't get me wrong, there's nothing that STOPS you using CSLA. However, making use of a framework does have a price (such as compromising your architectual choices and keeping up with breaking changes, to name but two examples.) It is a healthy practice to continually question what is the best technology choice in any given situation, so I am checking my justifications.

What are other people's experiences in this respect? Are the compromises still worth the payback? Do people continue to use CSLA despite these shortcomings (in the UI technologies?)

How/where do people deal with encoding output and sanitizing input in a web UI? Has anyone tried something like MVVM to help?



(shortened repost to save people valuable reading time!)

ajj3085 replied on Friday, July 15, 2011

Just so you know, what MVC calls model binding is basically databinding.  So its still useful (just use Html.EditorFor(x=>x.CslaProperty).

The validation is still really important.  Data annontations are great for simple things, but if you have business rules you'll have some more complex onees that you'll only want to run on the server.   The only difference is that all the properties will be set as a batch in a postback vs. one at a time while moving from field to field.  The business will want complex rules no matter what UI you use. 

N-level undo I haven't used in in rich clients, but for those that need it, its good to know its there.

The rest of your post clearly indicates the benefits you still get from it, and I agree with those points.  You still get a lot of value out of what you are using, and you don't need to re-invent the wheel for those features you'd still need anyway if you didn't use Csla.

My experience has been that Csla has been useful in a web app.  The structure of each BO helps you keep clear separation of layers, meaning your BO library will live long after MVC is replaced with the next big revolution.

I've already replace my DAL layer.  Didn't need to touch rules or the UI, it went very smoothly and I just had to worry about the data portal methods.  I've also (later) ported from WebForms to MVC.  Again, this was pretty painless.  I didn't change my BOs much, and where i did, it's because i had a bit of business logic creep into the UI.  It actually made the app much simplier, because MVC itself requires less code that WebForms (all that plumbing and event handlers, etc).

So my short answer is yes, it still provides a lot of value, and if you were not no use it, you'd be forced to re-implement the missing pieces yourself (validation, data portal, etc).

RockyRocks replied on Tuesday, July 19, 2011

Hi Andy,

Thanks for your response. Your points are all interesting.

MVC - data binding is used then, but of course it is only one-way binding. The cleverness of CSLA is in providing two way binding, which is a bit more involved and would not be used in MVC. The .NET 2.0 controls in WebForms support two-way data binding, but then the question of sanitization and validation against web vulnerabilities raise their head (and where those risks are mitigated).

I agree that there will always be a need for complex validation. I don't know how well you know data annotations but I understand the framework is straightforward to extend; you end up creating a class for a custom data annotations validation instead of a method for CSLA, but as far as I can see there is good support there. As data annotation uses reflection I think validation could be performed on combinations of many variables as complex validation would often require. Reflection isn't great, but that's what data binding uses and that is considered acceptable. There is no support for dependent properties in DA, but they are not required during batch validation.

I am entirely with you on how CSLA encourages good application structure, but my point was simply that you don't have to use CSLA to achieve that, it just helps.

I think I am more comfortable that CSLA is still the way, but any more thoughts would be welcome.

Many thanks,




Copyright (c) Marimer LLC