+972 52-548-6969
On the CAB: Again
I wanted to take some time to clear some issues regarding my previous post about the P&P. A lot of people seems to grab on to my mention of CAB (interestingly, no one tried to defend the DAAB :-) ), and the conversation has turned that way. Just to remind you, here is what I said:
The only other thing that people seem to have noticed is the part about developing in vacum, but I will touch that separatedly. Since so much of the discussion has centered about the CAB, I am going to discussed it specifically. I would like to mention first that I have not built a real-world CAB based solution. I have listened to a few presentations on it and pursued the quick samples and the code itself, however. By no means am I a CAB expert, but I believe that I am able to evaluate the CAB and its ability to meet my needs based on that.
A lot of the discussion has been about the technical merits of the CAB, and whatever it is useful to use that or not. I have a few issues with the CAB from a technical point of view, but nothing truely major. I even said so explicitly in my previous post. I am not talking about the quality of the code, or whatever it uses the right patterns, or allows you to write testable code.
I am talking about the whole approach that the CAB has taken. This approach is too heavy weight in my opinion. My approach to big, complex WinForms UI application would basically consist of hierarchical MVC, probably with an Event Bus and a common base class for the Forms. If hierarchical MVC sounds familiar to you, that is very similar to the idea of work items. The CAB approach is to re-structure the entire application around the CAB.
It may be a personal preference thing, but I don't like it when I need to do something in a completely different way because of a tool that I am using.
About the complexity of the CAB approach, just a few quotes (hopefull not out of context):
- From Sam Gentile: "...I was going to show how to tame this CAB beast..."
- From David Hayden: "I have never had the pleasure of working with the Composite Application Block ( CAB ) or Smart Client Software Factory ( SCSF )"
- From Bil Simser: "I've spent the better part of a year learning CAB, EntLib, ObjectBuilder, WorkItems, and all that jargon..."
Complexity is not a good thing, especially when it is exposed to the user.
Developing in vacum:
This is another thing that some people took offence at is that I said that the P&P develop stuff in vacum. Sam Gentile don't think that this is the case:
That may have started out the proper way, but "working with dozens of customers" it not what I mean about developing in vacum. Perhaps a better word would be dog-fooded. As in, you build stuff that you will use. So you see all the pain points, and you find out what is needed in order to smooth the wrinkles. I said it explicitly in my post, I want stuff that people are incentivized to make great for the oldest reason there is, because it makes their life easier.
Now, please correct me if I am wrong, but I do not believe that the CAB team is also a customer of the CAB. That makes it development in vacum.
Comments
I won't get into the developing in a vacuum part as that is an entire issue unto itself. I will mention that I totally agree that CAB is complex, but complexity comes with the territory. CAB isn't just a WinForm UI thing. As a few of us have said, CAB is a lot of functionality packed into a few assemblies. Dependency Injection, Event Messaging and Routing, MVP, MVC, etc. so yes, its complex because of it's size but it's not complicated. There's just a lot of moving parts. If I sat down and learned the entire StructureMap API, Castle, and a few other things I would probably end up stuffing my brain with just as much knowledge as I have with CAB (probably less).
PS no bashing or things taken out of context here. I think it's a very lively discussion, with no right or wrong. Just differing views, some overlapping, some not. I personally like it the threads going on as it promotes awareness.
Bank industry customer? Now it all makes sense to me as to why the CAB is so bloated. In my experience banks just love huge monolithic frameworks, which fits in with their "all or nothing" attitude towards software development. They just love to add in useless features and make their code bend to the will of "the framework". Since banks are about minimizing risk, I assume this is done out of fear of change (aka writing more code). Clearly an agile approach would dictate that you only build what you need now, but banks and their waterfall methodology definately fall into monolithic framework category. Clearly not all banks are created equal, but this has been my experience with them.
On the lighter side, if you compare the CAB to Weblogic and EJBs (which our a bank favorite) then I guess the CAB looks pretty good!
One thing that hasn't been mentioned about the CAB is that the license agreement may not be good for everyone. It is NOT by any means the MS-PL.
http://msdn2.microsoft.com/en-us/library/aa480452.aspx
Specifically I find EntLib and CAB completely unusable do to item number 10.
"That you may run the Software or modifications only on the Windows platform."
I like Mono. I like Linux. While I do my development under Windows, I like to think that it COULD be easily moved to run under Mono. EntLib and CAB completely remove this possibility.
Comment preview