Stack OverflowHave you attended the CSLA Master class?
[+5] [6] jdecuyper
[2008-08-04 13:40:35]
[ csla training-events ]

As anyone ever attended the CSLA Master class [1] from Rockford Lhotka?

It seems a good way to enforce my OO knowledge in the ASP.Net field, but since I have to consider the flight to Atlanta and the course's price ($2,500), I'm not convinced yet.

Also, I could barely find any feedback on the web. Could anyone share some experience or comments?

[+30] [2008-09-19 16:06:41] fuzzbone

I would consider second and third thoughts on using CSLA - but I wouldn't base it on the "accepted" answer above because it is completely inacurate.

Particularly this comment:

was a great framework back in VB days -ahead of it's time even - but it's very long in the tooth.

The .NET CSLA framework is completely rewritten from the ground up and bears little to no relationship with the VB version (other than some very high-level philosophy). Calling it "long in tooth" because the author wrote a different version in a different language would be like saying "Don't Use VB.NET because it's VB3 was a great lanaguage in it's day - but it's very long in tooth...."

Thee are a lot of good and bad reasons to use or not use CSLA - but as Rik points out you definitely can do TDD with CSLA. CSLA has a lot of really good features and for a lot of environments it is an excellent choice. I'll admit a biase up front -I work for Magenic (Rocky's firm)...

That said - the accurate answer about "The Alt.Net crowd" - is that CSLA does impose some limitations (because of the use the "Data Portal" in some of the tools that "the Alt.Net crowd" considers critical - particular depency injection. If you believe the only way to do TDD is to use dependency injection - only then would I say that you can't do TDD with CSLA.

Furthermore - mock frameworks like RhinoMocks use Dependcy injection can't be used as well. Typemock does not - so you CAN use mocking with CSLA.

So if you can't live without dependency injection and a particular Mock Framework (other than TypeMock) - you probably don't want to consider CSLA - but neither of those is a requirment to "Learn OO"...

[+9] [2008-09-02 16:31:32] Rikalous

Couple of quick points : I have used TDD on a CSLA project - works like a charm.

You are free to implement any data access method within a CSLA project - the data access code doesn't have to be inside a CSLA class.

CSLA is BDD - it's a very pragmatic approach to building a business layer for your application.

[+7] [2009-03-10 06:19:50] Gregory Higley

The way to use CSLA with TDD is simple: You have to realize that CSLA is not an ORM. (Repeat 100 times, because so many people miss this critical fact.) An ORM is something you might use inside CSLA's DataPortal_XYZ or Child_XYZ methods.

Let's take the popular Repository pattern, which is excellent for testing. The important thing to realize is that your repository is not a repository of CSLA objects. Rather, your CSLA objects consume your repository, i.e., they use your repository for performing data access operations.

So, how does this make CSLA testable? In the classic Repository pattern, you swap out your "real" repository with a test repository in your unit tests. This is exactly what you would do in a CSLA scenario. It's a bit of a pain to pass parameters to a CSLA object to tell it which repository to instantiate, so that would have to be configuration-driven, but the principle is perfectly valid. You can then unit-test your CSLA objects without worrying that they are hitting a live database.

As others have said, CSLA is not a data access technology. It sits between your UI and your persistence layer and provides services like validation, two-way binding, etc. It has methods to invoke various persistence operations, but those operations can be anything you like.

[+4] [2009-01-28 14:47:38] user59749

The latest version of CSLA is specifically for Silverlight so to say it's "long in the tooth" is simply untrue. I've used Visual Studio's testing facilities perfectly well with CSLA. It's really an amazing platform and I don't work for Magenic. I have attended the 3 day CSLA class and found it helpful but best for people with little to no experience at all using the framework. I'm also interested in the Masterclass but have yet to take it.

[+3] [2011-03-29 08:56:59] mark

I have a two years experience with CSLA. In fact, when I started our project I really did not want to write an entity framework from scratch, something that was done in all of my previous jobs.

So, I picked CSLA. As any entity framework, it has good and bad points. I will list a few of the bad ones, because the good ones are described in abundance on the CSLA related sites. So, the nays:

  • CSLA parent-child relationship does not support folder-file pattern, where files are children of the parent folder, but they are also independent entities. In CSLA, children are integral part of the parent, so you cannot, for instance, update/delete/add a single child without updating the whole object tree. Forget about lazy loading of children - no such thing. In short, if your data model represents a folder-file like structure - do not use CSLA. We had to twist CSLA arms to let it support this mode.
  • Huge overhead in terms of state. Define a business object with 3 properties. Now send it over wire using some http binding. Pay attention to what gets transmitted. I know XML is not the best serialization vehicle, but your 3 properties are translated to ~4KB of XML. What does it include? Business rules and field data manager state among others. Extremely bloated. We employ zip compression, but still this is very disturbing.
  • Silverlight does not have normal serialization engine, so CSLA comes with a Mobile serialization, which is good if there is nothing else. The thing is that there are other things - JSON and protocol buffers, but CSLA is incompatible with these techniques. And Mobile serialization, although it solves the problem, it is a real pain when it comes to commands, because there you have to implement it manually (unlike business objects, which support it automatically for each managed property). Remember CArchive from MFC of 10 years ago? This is it.
  • Saving an object does not merge the new state in-place, rather returns a new object. We had much problems in Silverlight with the fact that every save replaces the object tree. So, we had to override the CSLA default behavior and implement in-place save with all the associated complexity of merging new state with the old one.
  • You quickly loose control over what is actually transmitted on the wire. For example, here is something I have discovered while examining the CSLA source code. Serializing a business object also serializes all the serializable subscribers to its PropertyChanged and PropertyChanging events. So, when such an object is sent to the server, it carries along with it all the serializable subscribers to these events. From the mobile object philosophy this is fine - mobile object simply preserves its living environment across the application tiers. From the practical point of view I find this a disaster waiting to happen. Needless to say that I have disabled this feature right on the spot.
  • Looking back after 2 years working with CSLA I have came to a conclusion that many others already came to before - your server side objects just not the same as your client side. Trying to pretend they are yields a lot of grief later in the development. And this is probably the most important nay to CSLA. The concept of mobile objects seems right at first, but as the project grows and the server and client sides develop having the same object type on the server and client becomes more of a liability rather than advantage - the internet is full of discussions on the matter.

Bottom line - I would not have used CSLA if I had the same understanding as I do now back then when I have started the project. CSLA gives you much stuff out of the box and I like DataPortal concept very much, but I see that I could have done fine without them and be in a better place now.

These are my 2 cents.

You explained very well the main reasons why CSLA was created and how it works. Thanks for taking the time to share your experience! - jdecuyper
[+2] [2008-08-04 13:50:22] Karl Seguin [ACCEPTED]

I guess if you have to do CSLA it might be worth it, but if you're looking to enforce your OO knowledge, look elsewhere. CLSA doesn't promote TDD or BDD. It's hard to unit test. Your "object" get completely loaded with data access - doesn't seem OO to me.

CSLA is a narrow perspective on how systems ought to be built. It doesn't teach you OO, it teaches you Rocky's vision of OO. I know the ALT.NET crowd has been a little hard on CSLA, but I think it's for good reason. It was a great framework back in VB days -ahead of its time even - but it's very long in the tooth.

If you want to learn OO, go with an o/r mapper, get Evans' DDD book [1], and the free Foundations [2] series. You'll be considerably better off - have a more fundamental understanding of DDD, and most importantly won't be boxed in with a single vision. You'll have the agility to pick an ActiveRecord implementation if that suits your projects needs, or a full blown o/r mapper. Most importantly, you'll actually be able to unit test your code!


The Foundations ebook is great. Thanks for the link. - brun
(7) Your objects don't have to get loaded with data access. You simply create a data access layer and call into that layer, which can easily be mocked of course. Also CSLA has nothing to do with ORM, if this is what you think of it then you probably should take a second look. -
(1) I think your answer is way off base and I'm completely shocked that it was accepted. I suspect you have little experience with CSLA. The purpose behind CSLA is to have behavior driven design and as 'just in case' noted, there is nothing stopping you from implementing the repository pattern. Furthermore, you noted that 'if you want to learn OO, go with an o/r mapper'. O/R Mapper's are data centric, that is, objects are designed with regards to their data not behavior which goes against some of the fundamental ideas of OO design. - J.C.
(1) Sorry, this answer is completely off the mark. OO is all about state + behavior, which is exactly what Csla objects are. Your business behaviors, with the state they need to carry out those behaviors. Having built several Csla application over the years, I can firmly say Csla has helped me become better with OO. I learned to cleanly separate the various concerns; UI concerns stay in the UI, business in the business, etc. Given that I've got hunderds of tests for the projects I'm working on now, and that I always start with tests, I fail to see how Csla don't promote BDD. - Andy