CSLA: My Thoughts and Opinions

Retraction:
I have said a few times that there was a bug in CSLA, at least in an early version, where DataReaders do not get closed.  I should instead have said that this bug was in the examples of how to use CSLA, which are found in the CSLA book, not in the CSLA core framework itself.  That is a legitimate distinction, and I erred in not making it, but it should also be noted that many people follow these examples of usage.

Positive Note:
If you are new to object-oriented programming, or at least business objects, then I heartily recommend Rocky Lhotka's books.  The CSLA framework that he develops in his books is one of the best explanations of how to build a business object framework available (if not the best).  I owned the previous VB6 version, and now have a .NET version, and I can honestly say that I have learned from Rocky's books and speaking.

Negative Note:
As I have said a few times, and has apparently offended some CSLA groupies, you should never assume that any framework or tool is perfect or ready-to-use in your situation.  CSLA, like any framework or tool, may include things that you do not need which can make it heavy, it requires a commitment to learn, and it may not save as much time as other tools when used manually (without code gen).  Be prepared to make changes.

Disclaimer:
I sale an O/R Mapper, if you can call $50 and free upgrades for live selling, which I think is one of the simplest tools out there, as well as being easy to extend when necessary.  It has some overlap with CSLA, so it can be perceived that my comments are made to increase my sales.  Of course, CSLA and my O/R Mapper can most likely be used together, since what my mapper does is what CSLA leaves undone, and vice versa.

Personal Note:
I hope that this somehow proves that I am at least somewhat objective and positive, and not just "trash" talking, misleading, or being dishonest when it comes to CSLA.  There are many styles and possible solutions in .NET -- I have used CSLA on a major project and do not want to do so again -- but I can say the same about many other techniques I have used in the past too.  Feel free to similarly critique my O/R Mapper, but please don't make it personal and simply "trash" talk me for simply stating my opinions.  Finally, I would like to say thank you to the many people that have positively appreciated my comments in the past -- and were glad to know they were not alone in their experiences -- and I understand why most of you preferred to only communicate in private emails to avoid the very groupie talk that I have fell into.

14 Comments

  • I'm curious to know what didn't work for you (in the project you cited in your personal note) with the CSLA framework that would make you not want to use it again. I own Rocky's C# Business Objects book (and have followed his (and Billy Hollis) column on MSDN and have enjoyed the read but have had some "philosophical" differences in the CSLA architecture. Is it that you disagree with the concepts or the implementation? And why?

  • Lamont:



    I don't think I would say it didn't work -- although it was a heck of a lot of work in my opinion (still ongoing when I left). Part of that work was in removing a lot of the features that we simply did not need and which were causing excessive memory use. Granted our system was not typical (lots of large recordsets and on Citrix), and I blame management for not listening better there. But the real "work" to me was in creating my business objects, and making sure that all the dependencies were correct also. Some of that can certainly be alleviated in many projects with code gen, but I simply believe there are simpler ways to do things. I've also led enough teams to know that there is a huge difference in what some consultants teach and what actually happens. So I want something simple for my teams to use and learn and maintain, while still being flexible and easy to extend. I'm simply at the place in my career where I'm tired of the same old things -- and I strongly believe I've found better ways. I didn't invent these things -- I actually learned from several others in the forums -- and from reading what the Java folks do.

  • Your reply above says "I want something simple...I've found better ways...I didn't invent these things..."

    We're wrestling with simple/flexible .NET architecture issues like so many others, and your words caught our attention. Are the "better ways" and "things" in your reply referring to:



    a) commercial tools -- such as your O/R mapper, UI mapper, or other products targeting architecture/framework issues?, or

    b) concepts/ideas/practices that promote simple and flexible architecture, or

    c) some combination of a) plus b), or

    d) other!?!



    Simplicity/flexibilty are worthwhile targets indeed, but we're finding that the practical nut&bolts mechanisms to get there are not easy to pin down. How ironic that the path to simplicity seems... complicated!! So we're curious to have you unpack more detail about what you've found (tools? practices? specifics?...) that promotes simplicity in .NET architecture without sacrificing power, flexibility, extensibility, etc. Please elaborate. Thanks.

  • I agree with Curious Coder. Come Paul, spit it out :)

  • Our company is a long-time user of CSLA. Most everyone hates it but its too late to easily change now. We went with CSLA since we thought it would make maintenance easier. But we have to write so much code to get it to work that its just ridiculous. A framework should make things easier and not force you to jump through hoops whenever something needs done. I don't think it offers us anything at all that we need that isn't easy for us to have done other ways easier. We would recommend anyone just now starting to look around to look elsewhere. Go with one of the 3rd party frameworks that are much better. Or from what I can tell from just playing an object mapper would be another good alternative. But stay away from CSLA since its just to difficult and offers nothing much in return for all the trouble. BTW, we were also burned by the datareader bug in CSLA and as far as I'm concerned it is in CSLA since there is little difference in the book between example of how to use it and the framework itself.

  • I cannot believe that serious developers would take examples from a programming book and use them to implement real business solutions. I've just started reading VB.Net Bussiness Objects, and I'm glad that I have. However I would never consider blindly implementing the framework presented there. I will use the book to better understand the .Net framework.

  • Count me another disgruntled CSLA user. We did not follow it blindly. We just found it too hard for little gain. I find Wilson's mapper easiest and LLBLGen nice also.

  • The correct answer is (c) !



    O/R mappers go a long long way in helping to achieve simplicity, flexibility, and maintainability, as well as being able to produce results quickly. My first venture into O/R mappers was with Thona-Consulting's EntityBroker, and while its still one of the best I decided I didn't need the features that made it more complex than I could imagine. Lately I think NHibernate looks very promising, and its actually very similar to my WilsonORMapper from an external usage point of view, but its internal complexity makes it difficult to extend and its Hibernate heritage means its developers will probably not add new capabilities you want. I also think LLBLGen Pro is great if you like code gen, but that's still too complex for most teams I've been involved with. So while I think you'll be well off with any of those mappers, and maybe others, I do of course think my mapper hits the sweet spot of simplicity, both in usage and in its internal design for extensability.



    Of course O/R mappers don't cover everything, so you still have to create other parts of your architecture and applications. For UIs, I am personally using my UI Mapper, which I need to find a little more time to finish before I'll release it. But I also think you can do some absolutely great things with Code Gen in the UI -- I'm familiar with CodeSmith myself, but MyGeneration also looks promising. Log4Net is of course the answer to all your logging needs, NUnit is great for unit testing business logic, and there are many other similar tools you can piece together for pieces of your architecture. The beauty of most of these tools is that you can pick and chose the ones that fit your style and needs -- and most of them play well together -- resulting in a simple architecture that fits your team instead of a ready-made framework. And of course, keeping current of best practices and current concepts/ideas goes a long way into the choices you make, as well as the pieces you have to build yourself.



    In the end, there are a couple of things to keep in mind. First, every team and situation is different! I would never push the same methodologies or toolsets on every team or project -- although you certainly have to make some decisions quickly if its a new team that you don't know enough about, but even then you need to learn your team as much as your project. Next, know what's already available! I've seen far too many projects reinvent things that already exist -- whether it be things available in 3rd party or open-source tools, or things in the .NET framework itself -- so know the framework and stay abreast of what's going on. Finally, simplicity is a mindset that can be complicated! In other words, you have to actively strive for simplicity in many cases, and that's where refactoring is an essential tool that many project managers just don't get -- its a tradeoff between quick and easy now vs. flexible and maintainable in the future. I also find that many technical people are just too smart for their own good -- design patterns are just a tool, but many seem to think that they are an end to themselves.



    I'll try to blog this and more soon.

  • Paul - Response much appreciated. Thanks for jotting some more specific and helpful thoughts. Looking forward to more related blogging.



    Sam - you say "...Go with one of the 3rd party frameworks that are much better." Do you mean an O/R mapper or some other kind of product? Which did you have in mind? We're in an "evaluating/choosing" phase and thus very curious about such things.

  • We abandoned csla. It was nightmare.

  • Count another disappointment and abandonment of CSLA here.

  • Excellent post "jh72i". I guess part of my problem was that my boss at my last job was "sold" by some consultants that CSLA was the answer that we had to use. My opinions were belittled, my previous project was ridiculed (which was a quickie ASP.NET project that didn't justify an elaborate architecture of any type), and my boss was showed the book which proved it must be true. They told him that no using this tried and true framework would cost them months, both short-term and long-term, and yet later most of the other consultants were able to confide in me the opposite -- it was just the "sale" in other words. And that is my main gripe -- there are many people that should know better but talk it up in such a way that they convince others with less experience that it is a silver bullet. And that's also the exact same response that I got in those forums (from a small minority probably, but a very vocal one).

  • Hi Paul



    I think the value in CSLA or any other framework for that matter is that they promote consistency. Having been in the field for almost 20 years that counts for a great deal. Also, in my humble opinion a track record with a particular approach/framework is paramont to understanding it strengths and weaknesses in solving a particular problem.



    Looking forward to giving your ORMapper a try.



    Regards

    Kevin Weir

  • I have used CSLA successfully on several projects. Like anything else there was quite a learning curve and getting by in from other developers was also an issue. We relied heavily on mass code generation (CodeSmith) and unit testing. (VSTS) Without a good unit test harness I think you will not be successful with any OR/relation mapping tools.

Comments have been disabled for this content.