Ramblings from the Creator of WilsonDotNet.com
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?
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
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.
I find it completely understandable but not a little sad that people have had bad experiences with CSLA. I've seen this kind of thing a million times in a million companies (mmm, exaggeration there!) with every 'new' idea/methodology/example-of-how-to-use-a-technology.
Think about all the 'best practice' articles and building-blocks, examples, code snippets, whole bleedin systems, etc., etc. printed on MSDN over the years. Then think about how many times you have had to deal with code where the author didn't dig deeper, didn't use his/her own knowledge, experience, expertise, training, whatever but just blindly followed along ONE article or ONE book to guide an entire system or, worse, an entire company's software development strategy.
At the end of the day we are commercial software developers. Books do not give us the ANSWERS or FREE systems or frameworks or any such holy grail that means we never have to think again about our jobs. All these things: books, articles, examples are for our consumption to help equip us with a greater arsenal of knowledge to solve the next problem.
I love Rocky's framework. I have learned and taken a whole bunch from it, as I have from MSDN and all the other sources I can get my hands on – not least my own experiences! I use a framework of my own now that is based on, but is very different from, the EXAMPLE framework in Rockys’ book. Why is it so different? Because I develop COMMERCIAL software where every new system has its own peculiarities and my skills as a programmer is to adapt and solve in an efficient manner, bring what I can, create what I can't. And always consider the lifetime of a system and the way in which it will evolve.
By the way, Paul, I do feel that you came in for some harsh criticism from the CSLA forum. Well, you probably brought it down on yourself but you were gracious in the end. I feel strongly about how a single throwaway comment can lead to completely unreasonable negativity about a system/idea/book/…I have seen it cost good people jobs in the past. Thing about blogging is that while it may be aimed at specific professionals it is also accessible to people who are not in that audience! How many times have I had to reassure bosses of this or that after they come in all panicked after reading some comment in an article that they really were not equipped to read. How many times have we all had to sit our bosses down and explain the XML is not the end to all their problems – or web services or, now, SOA….???
Ok, my rant is over. All I will say to all involved it is don’t expect anyone or anything else to solve your problems – use whatever help you can get but put it with your own knowledge and experience because that is what you are getting paid for (not for buying a book or paying $50 dollars to a tool!). AND, share your experiences whenever you can.
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).
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.
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.