Thoughts on the Composite Application Block

The problem the Acropolis team had, was wanting to create a general purpose UI framework. The plan was to make it easy for developers to just implement the business logic, when designing applications for the line of business market. This was the driving force for Acropolis. What they soon found out, was that you need designers and very skilled ones at that, to create the compelling interfaces, something their budget did not allow for.

This whole area is ambiguous, because you can implement the Model View Controller framework in Windows Presentation Foundation (excellent example here), and using Windows Communication Foundation/Windows Workflow Foundation or ‘Workflow Services’ as they are collectively known, you pretty much get the design pattern alluded to beneath;

You just have the MVC client instead of the integrated/composite view.

You can manage the scalability of your smart/web client either on the client, or at the service level. If you use databinding in windows forms, you can databind the same logic to Windows Presentation Foundation. It’s still the same datasets/table adapters and so forth. It becomes immediately apparent that it is folly to use Language Integrated Query on the smart/web client because you cannot easily swop or use windows forms/WPF/Web clients, because your data access logic is inadvertently tightly coupled with the UI. Until Linq is developed to easily allow for usage in service based scenarios, and you do not have to jump through technical hurdles and cross layer obstacles to get it to work, steer well clear of it.
If however your business logic resides in the service/workflow, or n-tier datasets/stored procedures, you can service all three with very minimal effort. I have an application that is smart client (windows forms) based, but the WCF service can easily ‘service’ a web or WPF client (once WPF stops running like a dog with three legs).

One can then concentrate solely on the creation of an attractive user interface.

A digression is that, SQL server 2008 now has intellisense and a host of features that pretty much allow for the composition of SQL queries as you would in a rich IDE like Visual Studio using SQL Server Management Studio. With the present rage in functional programming (concurrent programming) and SQL being a ‘functional language’, I actually enjoy creating my data access on the server, for all the ease Linq gives. SQL is a purer functional language than C#, and I prefer it. With concurrency being focused on, just the fact that SQL is functional, means that if your data access logic resides on a many core server, the concurrent data crunching occurs on the server, rather than in parallel Linq queries (ad-hoc ‘for’ loops) on the client. This results in an extremely well performing application. WPF/Silverlight can then consume the limited resources of the client machine

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s