CSLA Master Class

Question

Hi guys! As anyone ever assisted the CSLA Master Class from Rockford Lhotka? (www).

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 barrely find any feedback on the web.

Could anyone share some experience or comments?

Thanks a lot.

Answer 1

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, and the free Foundations 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!

Answer 2

Wow, thanks a lot for your detailed answer.
I will certainly have a second thought now :)

Answer 3

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.

Answer 4

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"...

Answer 5

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.

Answer 6

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.