Microsoft Composite Application Block

Thursday, August 3rd, 2006 | Articles
The greatest programming project of all took six days;
on the seventh day the programmer rested.
We’ve been trying to debug the !@#$%&* thing ever since.
Moral: design before you implement.
(c) Usenet
 

Microsoft Composite Application Block is a really nice guidance asset to the world of creating feature rich smart client applications (those are words from the MS))). This is really a nice set of files and documentation that was created to provide developers with a guidance framework that utilizes some common real-world practices of creating GUI applications with complex and yet modular structure. This introduces separation of different application layers, ability to develop, implement, test, distribute and maintain application modules in a separate and yet unified and reusable manner. Sounds great to me. IMHO, there are some problems with the MS CAB:

  • It has quite a learning curve (all this code injection, MVC-MVP pattern implementations, WorkItems etc are way to much to get over within a day)))) However the time spent on getting yourself familiar with this AB is a wise investment.
  • MS CAB is a solution that tries to be universal. As we all know Jacks-of-all-trades never perform that well in specific application areas. A great try, however.
  • Using strings to reference different items feels quite weird. We’re in the modern world of IntelliSense, compile-time checking and LINQ, after all )))
  • Item number 10 in the License agreement of the MS CAB states “That you may run the Software or modifications only on the Windows platform“

Now here’s why this last item in the list bothers me. Mono seems to be the natural target for the application of MS CAB. It is even possible to get over that “you have to use Gtk# instead not-that-portable Windows.Forms” disadvantage with the Mono+CAB combination. However, Microsoft does not want to do that (either intentionally or unintentionally). So, the only way to reuse those guidance assets within Mono projects to rewrite the code (we are not talking about running mono-compiled application on windows only, are we?))). We’ll have to “port” ObjectBuilder and CompositeUI adapting those for the specific (and yet generic enough to be profitable) application areas. CompositeUI.WinForms, on the other side, has to be rewritten almost completely using the Gtk# and some type of “common building blocks” approach). That’s enough for today’s studies. I’ll get back to that topic of Mono+CAB later.

No comments yet.

Leave a comment

RSS

Search

Archives