CSLA - first base was fun, but I want a relationship
The scene opens on a typical fall Saturday evening at the local sports bar filled with enthusiastic football fans cheering loudly at the myriad of TV screens scattered around. In one small corner sitting around a high table is a group of people visiting about software development. Two guys, eager to make friends, walk up introduce themselves and let slip they’ve been developing software with CSLA for the past few years, and are looking for redemption.” The rest of the table then looks at each other and responds in chorus, “I’m Sorry!”
The shock on their faces at the collective “I’m Sorry” was a bit much. They knew some people have very differing opinions about different frameworks and tools, but hearing it confessed out loud was a breath of fresh air.
Recently our development team decided to stop developing with the CSLA framework. Before I get into specifics, I want to be very clear about something up front. I have no problem with people that continue to use CSLA. We used CSLA for nearly 4 years and it has worked in way it was designed.
While Hiren and I were at KaizenConf in Austin we made sure to find a few minutes each evening before getting caught up with a large group, to recap the day and share some new things we each learned. One of these nights while relaxing and evaluating what we’d been learning we came to the conclusion that it was time for us to step away from new development with CSLA and migrate existing codebases as well. Over the past week we have been outlining and discussing these ideas and why we have made the decision to move away from CSLA.
It all started a few months ago when we first started getting introduced to the Alt.Net ways of developing software. What I mean by the Alt.Net ways are things like S.O.L.I.D. principles, ORM use, unit testing, Domain Driven Design, Mocking, TDD, etc… All of this has really changed the way we think about and develop software. Even before this though Hiren and I made a very dangerous combination of developers because we are never satisfied with a piece of code once it is written, we usually have to talk one another into just leaving it alone because it works and is as good as it needs to be to get the job done.
There are several driving forces behind this decision, but the primary one is that our CSLA business objects just leave a bad taste in our mouth. Our systems are moderately complex and it is not uncommon at all to have a class with 1500 – 2500 lines of code, in fact that is probably an average line count in most business objects. The other thing that really smells to us is that the “model” contains a lot of stuff that is not directly related to the model, namely data access.
I would like to take a minute to point out some of the things I really like and will miss about CSLA, and some of the other reasons for making the switch.
CSLA, I will miss some of you:
- Validation Rules System
- Data binding Support
- Combo of these == reach UI validation for user
- Good set of guiding principles and samples to get started with.
- Rocky’s Books!
I won’t miss these parts though:
- Data Access code in business object
- Difficult to mock out data access in mocking
- N-Level undo – I never, ever used this but had to contend with it, like it or not
- “Super” Classes
These are purely my opinion so take them as they are. I still think CSLA has a place for some people and unlike others I have run into on the internet, I will not bash you or think you are stupid for using it. CSLA was an excellent stepping stone for us; it introduced and really engrained the Object-Oriented Programming style of thinking into our minds. I/we just feel like we have matured to a new level of development through better understanding of our software development process and how apply those skills to our situation.
We are still learning and don’t yet know exactly what our development style is going to be end-to-end on this project. We have a long way to go before we are completely comfortable with all these new tools. Luckily, the Alt.Net community seems to be an open and accepting group and nearly everyone is willing to help us out along the way.
What I do know is that no team can just take what one person or one book says and do it that way. It won’t work. What we are doing is educating ourselves on different practices and tools and using what works for us, we do a lot of spikes right now. We are also building our domain model with POCO’s which gives us a great amount of flexibility in the infrastructure and presentation layers of our system. As we continue this process I will post successes and failures here on my blog.
I have to ask you if you are have used remoting or wcf with CSLA because if u have then how are u know building the transport layer with u POCO NH objects.
I am asking because I am about to build my first Silverlight app and like you i like POCO but CSLA has all the plumbing in place. can you share some thoughts about the transport layer u are using if any?
Congrats for not bashing what you left behind. Csla has its merits… its just out-dated!
For complex projects it’s just not good enough. And it is definitely not TDD friendly.
@Martin
As I have said before we are a small company and all of our apps so far have been winforms. When we initially started using CSLA we tried using the remote dataportal but performance was not very good. Instead we have just given all clients a connection direct to SQL Server through the application. I would say that if/when we get to that point I would probably write something myself. A quick search for remoting in the Alt.Net group on yahoo returned some promising results as a place to get started. I would probably use some type of service or messaging bus to do the communication between the layers.
@Gabriel, Thanks for your kind words and all the help you have given me so far, and hopefully will continue to give. I really appreciate it.
I have used the CSLA validation system code as a basis for custom validation libraries. There’s no real reason to leave it behind. It’s a fairly good implementation of a fairly common pattern. Take what you need, customize it, test it, and leave the rest behind.
Rocky’s team worked so hard on the new “Object Factory” trying to make TDD developers happier. They will be disappointed.
Are you going to build some kind of your own “Application framework” to implement those missing features from CSLA?
@Frank, Yes they did work hard on the object factory and I have a fully working tdd style implementation/extension of their object factory out on google code, I can post a link if you want. That is the road I was initially going to go down, as I had that working, but the more I stewed over the problems I listed above, the more dissatisfied I was. So in the end I had to do what I had to do.
As far as my own “Application Framework”, whew, that is a very daunting task especially for somebody so wet behind the ears. I would imagine that most everybody has their own “Application Framework” when you get right down to it, I mean Ayende uses RhinoCommons as a starting point or a foundation to build off of in most of his projects. I would imagine I will have something similar that has my own magic pixie dust sprinkled on it at some point.
Thanks Ryan. I don’t think we will use CSLA.ObjectFactory at all. I don’t like to see too many magic attributes in our code. StructureMap inject in our BO is good enough for TDD purpose for now.
I do wish some AltDotNet genius can create a more TDD friendly “application framework” someday.
Ryan, I began to love CslapTrackerFactory is a good job, but I think your reasons for change are very valid, in fact I will continue to monitor your progress on the new road.
But my question is, What will become of the project CslapTrackerFactory? leave it completely? or transferred to another of us go to work?
@Jorge,
I think there is a couple of things with regards to StructureMap with the CSLA Ptracker Factory that I need to fix/make better. That was one of my first stabs at SM. As far as the project goes, I will pretty much allow anyone who wants to be a contributor, even if I am not using it. I think more tests need to be written against it if development continues, so I guess that would be my only requirement, a good faith attempt to test anything new that is written and possibly some legacy code.
Send me and email at [name@domain.com] where name = ryan and domain = techfocus2
If you’re not remoting via the dataportal then I understand why you are moving away from CSLA. Also, data access code in the business object only makes sense in the context of a distributed business tier where business objects are passed by value. However, if your applications are just making direct connections to the database (that is, simple two-tier applications) then CSLA is much more than you need. It is a framework for developing scalable N-tier applications where complex business objects can be passed from tier to tier. CSLA is a good model, it’s a robust model, but if you’re not doing N-tier, you don’t really need it. But let me ask this. Why aren’t you doing N-tier? It seems to me that your real decision was to not implement N-tier solutions, and that moving away from CSLA is just a natural (although delayed) consequence. N-tier (where N>2) versus two-tier seems to be the real issue here.
Hi Ryan,
I’ve been feeling exactly that same with about CSLA. However, I can’t make a clean break from CSLA like you have. I’ve been playing around with a solution that tries to make TDD and CSLA play together. I have started to write a series of blog posts on this. If you are interested, please check it out.
http://leighalsteris.blogspot.com/2008/12/tdd-friendly-csla-solution.html
Buy hydrocodone online….
Buy hydrocodone. Buy hydrocodone online without a prescription. Buy hydrocodone online….