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 will start off by giving my regular disclaimer, I am not an expert on this, however, I am also not an idiot either.

How It Was

We have been using Csla as a business object framework for about 3 years now and have had good results with it. That and we like things to just work and it does. Now a few months ago we started to get introduced to the altdotnet way and have seen the light and the need for many of the principles of altdotnet in our organization, it just makes sense. A few weeks ago Rhockford Lhotka release the beta version of Csla 3.6 and with it he has introduced support for an extensible ObjectFactory. This custom ObjectFactory takes the place of the DataPortal_XYZ() methods in the business object.

Now with the old way I had to make an object and write at least 3 lines of data access code for every property. This is cumbersome and just plain stinks. But good news! There is a better way.

The Better Way

So with this new ObjectFactory in Csla I can now spread some altdotnet goodness into my Csla projects. To be more specific here is what I have done, this has increased the dependencies of the project but has made the code much more flexible and easier to test.

• NHibernate – Powerful ORM
• StructureMap – Powerful yet fairly simple IoC container
• Fluent NHibernate – Let’s just say I loathe XML
• Lots of Unit Tests – Safety net

Hopefully this little overview has intrigued you enough to go download the source code for the Csla sample redone with an ObjectFactory implementation. The source code and zip file are available at http://code.google.com/p/cslaptrackerfactory/ I will update the repository as I make changes/ additions to the code. I have created this as an open source project because I know that my method is not the only method and hopefully we can collectively come up with a way to use Csla with altdotnet goodies in a more standard way. So with that said, if you want to join the project, drop me a line.

I will post more articles that go in depth on how/why I did things a certain way in this project later, I hopw.

Tags: CSLA, Development, NHibernate, StructureMap

We have been working the past few days on getting the new ObjectFactory up and running with CSLA 3.6. The approach we are taking is that we really want to abstract the Data Access Layer away from the Business Object so that we have some flexibility in the future to change the way we access the database. At the current time we are planning on using NHibernate as our ORM tool, one especially nice feature is that it is able to load your objects automatically so no more LoadProperty(SomeProperty) or ReadProperty(SomProperty) a million times. This one thing alone makes this very appealing to me.

This diagram above is a representation of the basic architecture of the system. What we are basically doing is using the Repository pattern to keep data access decoupled from the business object through the use of the ObjectFactory and StructureMap. This is a setup very similar to what Frank is using in his project. However we are not using DTO objects in between the Repository and the business object. We might change this later but for now we will let the ORM load the objects directly.

I am currently working on implementing the ProjectTracker from the CSLA examples. My goal with this is to accomplish several things:

1. Learn the ins and outs of the ObjectFactory and how it works with StructureMap, NHibernate, Mock Objects, TDD, etc..
2. Provide a working drop in replacement to the “stock” ProjectTracker.Library, there shouldn’t be any changes required to the UI or anywhere else.
3. Provide the source code so others can learn from what has been done and make contributions to make it work better or smoother and have it provide a model for people to base their frameworks off of.

So stay tuned because I will be adding more information here as I get closer, should be real soon. I will probably setup the source code on Google code or codeplex, if I do that let me know if you want to make contributions to the project.

Tags: CSLA, NHibernate, StructureMap, TDD

So we just started hacking around on a little project this afternoon where we hooked up a basic CSLA business object up to a database with NHibernate + Fluent NHibernate. All I have to say is that this was a breeze. There was a few nuances that had to be figured out before the object returned from the database correctly but that was just because I was doing something wrong I think. I am going to expand my sample some tomorrow and will try to post more code samples and the project soon.

Tags: CSLA, Development, NHibernate