Smart Clients, Visual Studio 2008, and connecting the dots…

As I looked at the Patterns and Practices upcoming releases web site (http://msdn2.microsoft.com/en-us/practices/bb232643.aspx) and remembered reading some interesting posts about Acropolis not being included in Visual Studio 2008 but getting released later in 2008 (http://blogs.msdn.com/brada/archive/2007/06/05/some-common-acroplis-questions.aspx), I am afraid I connected the dots…

Neither the Smart Client Software Factory (SCSF) nor the Composite UI Application Block (CAB) are going to be released in a Visual Studio 2008 compatible release.   And Acropolis won’t be there until later in 2008.   This tells me it’s safer to continue smart client development using Visual Studio 2005 until after Acropolis has been released.

 I am currently installing the factory on a virtual PC in which I have installed Visual Studio 2008 so I can figure out what will be involved to get this guidance package to run in Visual Studio 2008.  We’ll see how far I can get without running into a brick wall…  More on that later.

Smart Clients and Service Granularity

In this post, I want to talk about service granularity in a smart client application.  By service granularity, I am referring to the continuum of the scope of data that can be returned by a call to service.  On the low end of the continuum, I would get a single data element (that’s extreme and nobody that I know of does this in today’s distributed applications – that’s more akin to CORBA and DCE, both of which are no longer current).  On the other extreme, I’d get a complete object graph for a given business entity.  In fact, the dilemma is the granularity of the data transfer objects (refer to Martin Fowler’s documented enterprise application pattern at http://www.martinfowler.com/eaaCatalog/dataTransferObject.html).

In smart client applications, I often use several tabs to display information about something.  For example, I could have a customer screen with a personal information tab, account tab, preferences tab, and order history tab.  Now I have a choice: (1) make one call to a service and get a data transfer object to represent the customer and related information for all the tabs in one fell swoop; or (2) make a service call to get a data transfer object for the personal information tab, and make an additional 3 separate calls to the service in the background and fill the tabs when the information comes back.  The advantage of doing this is that the call to fill the first tab results in a smaller payload and thus should result in a faster response.  The disadvantage is that a total of 4 calls were made and it would be easy to fall into the trap of designing the services to fit a particular UI paradigm, a no-no in “service oriented architectures.” 

I am trying to find a happy medium where I first think about what the service should look like from a business perspective, while accounting for different ways in which UIs might consume the service.

Please post your comments on this topic as I am interested in finding out what others’ experiences are in this area.