CSLA

We've been looking at this framework at my work for a while as we believed NHibernate + CSLA could allow us to get the advantage of an approach like .netTiers but with a few advantages:

1. No need to generate large amounts of code.
2. We would only use the features we need.
3. Seperate, to a large extent, the design of the domain and database.

Anyway although CSLA seems like a good framework if your not going to use the mobile objects approach, and we aren't, then it adds a lot of complexity for very little gain. In particular for a Web application I'm not sure how realistic CSLA is. In our case we didn't like the delegate based rule code, we don't need multiple level undo, we don't need dirty tracking....

Having said that the binding code and a few other bits could be useful.

One bit I did find very odd in my reading about CSLA was the fact that call your persistence code from your domain objects was justified for encapsulation reasons and to avoid using reflection as it can hurt performance.

The reflection argument seems pretty redundanct as CSLA itself uses reflection quite widely and the cost of reflection isn't likely to be noticable compared to things like database or network calls.

Likewise the encapsulation argument seemed a bit questionable, there are certainly good arguments for not putting your data access code in your domain/business objects and indeed for not accessing the data access code from your domain objects.

Anyway so far we've used CSLA pretty sparingly and even the bits we have used, like the validation framework, are slowly being engineered out.

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone