I have to agree with BIl on this, and this is not just based simpy on personal bias, rather it is based on what cusotmers have told me. SInce taking my current role, I have spoken to literally hundreds of customers that have used CAB / SCSF, and it boils down to this. 

For large organizations, essentially they love it. When I see large for example I am talking about a 100K employee customer that I recently visited in the UK. They have a framework team responsible for determining the infrastructure to use and architectural standards for literally thousands of projects. They don't have the time, or inclination to build either one uber framework, or a million and one customized frameworks. For them the very fact that CAB is an uber-generic frameowrk gives them more hope that they can use it throughout the org, much like they can use the .NET framework. Now does this mean the love very aspect of it? No, but it means that the benefits outweight the cost.

For smaller organizations, it's a mixed bag. Some choose CAB even though CAB was not really built for them. Meaning if you have an application that is maintained by a small team of developer, then although CAB "can" provide benefits, the cost of getting those benefits may not justify the investment. However, in other cases even in small companies there are those that have found alot of benefit. Others have found that CAB helped them signficantly in providing a means for developing in a more decoupled fashion and testable fashion. As I've said, it's not perfect for sure.

Now my personal opinion is it really comes down to three things

1. What kind / size of organization you are in.

2. What kind of application(s) you are building

3. What the team makeup is.

Ultimately I agree with Jeremy. If you are willing to invest in building your own framework of sorts that is harvested out of your existing apps, that is by far the best solution. You will end up with something that completely meets your needs. If you go with CAB, it may or may not meet your needs, however you can spend some up front time to evaluate it and make that decision. 

It definately has a learning curve, and will be overkill in some scenarios.

As far as competitors, there aren'y many frameworks in this space that are focused on the UI composition problems that CAB addresses. There are plenty of DI containers (Castle, Spring, etc) but they address different concerns of dependency injection and wiring.

There are some third party options you could consider including the new Dev Express XAF framework. I haven't looked at it so I can't really speak on it. What i have seen leads me to believe that it may suffer from some of the same concerns you have about SCSF/CAB.

On Jan 8, 2008 5:37 PM, Bil Simser <emailme@...> wrote:

I agree (and practice) the build as you go approach. Thumbs up there. However when you have 5 projects starting at the same time and they all need different aspects of a framework and all parts need to work together, that's a monster of co-ordination IMHO. Maybe not impossible but adds to the complex level of integration and organization. Almost need a separate organization approach to the framework development (maybe via a Scrum of Scrums with a single member of each consuming project team representing their part of it) to keep on top of things. Definitely not something I would want to try to manage.

 

From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Ayende Rahien
Sent: Tuesday, January 08, 2008 6:29 PM

To: altdotnet@yahoogroups.com
Subject: Re: [altdotnet] Alt.Net alternatives to CAB, opinions, pros and cons

 

Build as you go is a really good approach, I have found.
This means that you build what you need, with the knowledge of how to best structure that.
It is also very easy to get things started and then to keep them rolling.

On 1/9/08, Bil Simser <emailme@...> wrote:

So what do people think about this approach though? I may be playing devils advocate here (and trust me, I curse CAB up and down some days) but there's a cost involved here.

 

For example, can you really on a project say "we're going to write our own framework [using Jeremy's blog posts as a guide] because CAB is too big|complicated|half-baked|whatever". If I was a paying customer of that software I would think about this for a second and say "there's a framework you don't have to write but might be overkill vs RYO from scratch". Are you delivering customer value quickly and effectively if you build your own from the ground up? What companies can operate like this and fund this type of thing. I know when a project gets funded (if you're in that model) you have enough budget to build the software, not build all the glue needed to build the software. So how are you selling this approach?

 

I'm not saying CAB should or shouldn't be considered or chosen purely because of costs. I'm a strong proponent of long term cost and some things cost more in the long run than the short term. However, the NIH syndrome can be very costly. Every line of code I write (app, framework, or tool) is legacy code someone has to maintain someday.

 

Maybe the build your own CAB series needs a downloadable deployable assembly that someone can use and it just works.

 

From: altdotnet@yahoogroups.com [mailto: altdotnet@yahoogroups.com] On Behalf Of Joe Ocampo
Sent: Tuesday, January 08, 2008 1:38 PM
To: altdotnet@yahoogroups.com
Subject: Re: [altdotnet] Alt.Net alternatives to CAB, opinions, pros and cons

 

For any WinForm work I always turn to Jeremy Miller's series on build you own CAB.  He built it with testability in mind and that is what I value most.

http://codebetter.com/blogs/jeremy.miller/archive/tags/Build+your+own+CAB/default.aspx