Developers Taking Punches at the CAB ( Composite Application Block ) - Keeping the Composite Web Application Block Lean and Mean
by David Hayden ( Florida .NET C# SQL Server Developer ), Filed: Web Client Software Factory
I have never had the pleasure of working with the Composite Application Block ( CAB ) or Smart Client Software Factory ( SCSF ), albeit I did download the SCSF v2 to get Enterprise Library 3.1 this weekend :) I guess the CAB and Microsoft Patterns & Practices were a controversial topic at the latest DevTeach according to Jeremy. It sounds like some people believe the CAB has perhaps gone too far and pidgeon-holed developers in how they have to do things. This may or may not really be the case, but either way, this is the very thing I hope does not happen to the Composite Web Application Block ( CWAB ).
The CAB and CWAB share some basic principles and technologies regarding Dependency injection, Service Location, the View-Presenter Pattern, etc. I personally think the CWAB does a pretty nice job of helping me with those infrastructure and cross-cutting concerns that are common to all my applications and leaving me free to do the application specific development as I see fit. Sure, with any framework you have to abide by some rules and programming standards to get consistent and useful functionality, but the CWAB is pretty good about staying out of the way and I would like to keep it that way!
One challenge with keeping the CWAB lean and mean is that often the developers who vote on new features for software factories and application blocks are very narrow sighted. They don't look at the big picture and they don't give thought to exactly what should be their responsibility, the responsibility of the framework, and the responsibility of the GAX/GAT. It is like I said before, be careful what you ask for as you might just get it.
We have to make and keep the Composite Web Application Block Lean and Mean. The developers on the P&P Client Team will be happy to play with all the latest cool technologies, but we need to make sure they are solving real problems and not just satisfying their technical curiosity or putting together needless bells and whistles. We also need to make sure they don't build a monolithic beast such that we end up getting and paying for functionality we don't need in an application. In addition, we also don't want them pidgeon-holing us into a particular solution that is not ideal, such as ObjectBuilder, when instead we should have been able to plug-in our dependency injection tool of choice from the very beginning.
Now is the week that P&P begins to look at new features for WCSF v2.0. We need to keep them on track. I really don't want them going crazy with AJAX and Page Flows when they still don't have the fundamentals of Dependency Injection, Service Registration and Location, and other fundamentals complete. Most importantly, since the same team does both the CAB and CWAB, we don't want them to just port over CAB code to the CWAB if it doesn't make sense, is bloated, or forces us into a corner about technologies and solutions. The CWAB should make our life easier on those tasks common to all applications and not get in our way.
The next version of WCSF is critical to its success and I would love for the P&P Team to kick some tail on this one.
Source: David Hayden ( Florida .NET C# SQL Server Developer )
Filed: Web Client Software Factory