Using CAB with MSF for Agile and Team System?

Topics: CAB & Smart Client Software Factory
Jun 29, 2007 at 10:47 PM
I'm researching CAB for an upcoming project, which will be a fairly complex back-office enterprise application. I've been doing quite a bit of reading about smart clients and CAB, but one question keeps nagging me: this use case thing. The white papers, articles, and online books I've been reading tout the "use case driven" aspect of CAB, which sounds nice, but if it's going to get in our way, not so much...

We are following the Microsoft Solutions Framework for Agile methodology, which makes use of Personas, Goals, Scenarios, and Storyboards. We have fully adopted Team System, and we're using the MSFA Process Template. We're also very likely going to be adopting the stpBA Storyboarding tool, which integrates with Scenarios defined in Team Foundation Server, and pushes Task work items back to Team System for the "forms" that appear in the Storyboard.

So given this, you might see how I'm nervous about this "use case" and "workitem" thing in CAB. Is CAB fundamentally incompatible with MSFA's Scenarios, which are at a lower granularity than use cases? Can I use CAB without worrying about use cases? Or even trying to shoe-horn Scenarios to work with CAB instead of use cases?

On a related note (in addition to this use case concern), we don't care about "composability" below the module level. Mostly what attracts us to CAB is the smart client shell and related plumbing. We're just building fairly normal Winforms applications, and we've decided that Smart Clients are the way to go. CAB seems to offer a nice way to solve some common infrastructure problems, but I have a fear that CAB is going to be more than we bargained for, or that it will require adoption of design patterns we just don't have a need for. Dynamic discovery and loading of modules at runtime sounds like a great feature, but below that level, we don't care about applying those dynamic capabilites, and would prefer not to bother with any overhead assocatiad with control-level dynamic composition.

Is CAB what we're looking for?

Any insights or comments are greatly appreciated.

Dan
Jul 12, 2007 at 6:24 PM
Edited Jul 12, 2007 at 6:25 PM
At the risk of sounding like a whiner, I thought I'd take one more shot at highlighting this thread on the chance that someone who missed the original post might have some comments to offer. In case I rambled on too much in my original post about what my concerns/questions are, it basically boils down to this:

1) Since we're using Microsoft Solutions Framework for Agile, we are not modelling around use cases, but rather scenarios. Is that going to create an impedance mismatch of sorts with CAB? Given Microsoft's push behind MSFA and the MSFA Process Template for Team System, is this something that's on the CAB community radar?

2) To what degree can we use CAB without worrying about the whole "use case" aspect of CAB? Can we just design and code "normal" windows forms apps and run them as modules within the CAB shell? Or does adopting CAB mean that we pretty much have to adopt a particular "methodology" for designing and coding lower level elements such as forms and controls?

Thanks,
Dan
Jul 12, 2007 at 8:29 PM
Dan,

No one thinks you're a whiner :-)

But the questions you asked raise a level of concern with me (I can't speak for anyone else on the board). I am wondering what your level of expertise is with Agile and .Net, because the questions don't always make sense. I'll elaborate in my answers below:


Given Microsoft's push behind MSFA and the MSFA Process Template for Team System, is this something that's on the CAB community radar?


No. Honestly, until you posted this, I had no idea MSFA existed or what it was. I had to look it up to see what it is about. It sounds like a project management tool.

I don't know how many people using CAB are doing Agile, but I suspect it is a pretty fair number. I know we are following an Agile methodology where I work.

But CAB is a framework for building applications, not a methodology for developing software. So you could use CAB in a shop that used Waterfall, Scrum, Extreme Programming, or whatever other methodology you like. It doesn't matter. Methodologies only recommend how you should write code. Frameworks assist you in writing the code by providing code (in the form of code generation, factories, wizards, templates, etc.) that is designed to solve common, repeating problems.

Now, I could be totally wrong about MSFA, but it doesn't sound like a framework from what I've read, and I haven't read anything about it to suggest that it produces code, either through code generation or templates or factories.

To me, MSFA sounds like a project management tool. I guess I can see where some people might want that, but personally I'd rather just read Kent Beck's books on Extreme Programming and manage the project with story cards :-)

Of course, like I said, I could be totally wrong about what MSFA is, and I hope you'll correct me if I am :-)


Since we're using Microsoft Solutions Framework for Agile, we are not modelling around use cases, but rather scenarios. Is that going to create an impedance mismatch of sorts with CAB?


I don't see how, with my limited knowledge of MSFA. The "scenarios" sound a lot like an abstract, managerial concept with no real code - just a way of thinking about something. A Use Case is something you model with actual code. CAB doesn't actually have a "Use Case" class or anything; it's just a way to conceptually think about code that is related (workItems, presenters, views, services, etc.) to solve a particular problem from a user point of view.


To what degree can we use CAB without worrying about the whole "use case" aspect of CAB?


You can use CAB however you like. Use Cases are just a common abstract way of thinking about things related code, so it's an accepted terminology for those who use CAB.


Can we just design and code "normal" windows forms apps and run them as modules within the CAB shell?


You can, but you'd be missing the point of using CAB. CAB is designed to encourage the MVP pattern for Forms development, which allows for some degree of decoupling, separation of concerns and testability, all Agile tenets. "Normal" Windows Forms, at least in my experience, are usually jumbled balls of code where all logic is built right into the Form. Maybe that's not what you meant though.


Or does adopting CAB mean that we pretty much have to adopt a particular "methodology" for designing and coding lower level elements such as forms and controls?


No. CAB is not a methodology. It's a framework. There's a big difference :-) What CAB does do, however, is strongly encourage the use of an accepted design pattern, MVP. Design patterns are not really related to design methodologies, because you could use any particular design pattern with any methodology ( you could use MVP in a shop that practiced Waterfall, if you really wanted to)

A methodology describes how code should be written. (Waterfall says "do all design up front, test at the end", for instance, while Agile says, "design a little bit at a time, as you go, and always be designing and testing your code").

A framework is a totally different animal. It is there to assist your development team in creating the pieces that make up the application by providing code, wizards, templates and other things to assist you in defeating common, repeatable problems. A framework is mostly independent of the methodology used to govern the process of writing code. I say "mostly independent" because some frameworks can be inflexible, and they would make poor candidates to build on in an shop using an Agile methodology.

I think (and this is just my personal opinion) the question you have to ask yourself is: Why are we using MSFA?

I can give you a bunch of reasons to use CAB. But I don't think I know enough about MSFA to tell you if it's a good or bad thing.

Jul 12, 2007 at 11:25 PM
Hi Chris,

I very much appreciate your taking the time for your response. I know how hard it is to take the time out and answer everyone's questions, but hopefully this thread will become something that others in my position can use for information in the future.

I think before we can move forward much further in this discussion (if you don't mind continuing it) I need to explain myself and the assumptions behind my questions a little better. I'll do my best to explain myself further as quickly as I can, but I'm afraid this will end up long.

On Framework vs. methodology, the particulars of Agile methodologies, reasons for choosing methodologies, etc.: I'm with you 100%, and I am fully clear on the differences. That said, I think I can see why the way I phrased my questions might make it seem like I'm operating from mistaken impressions.

Also, on MVP (or as we call it in our shop MVPC) and the related MVC patterns, I'm with you there 100%. I'm familiar with the pattern generally, and also they way the pattern is central to the latest software factories in the Microsoft universe. We are actively using the latest P&P software factories in our shop, but have not yet adopted them for winforms/smart client development. I'll get into what I meant by "normal winforms" a little further down below.

Before getting into why I'm asking about CAB in relation to MSFA and about use cases vs. scenarios, I think I should explain why I see this as relevant. Reading your response, I see now that my original post could have been improved by this explanation.

The design of CAB is often described in terms of the importance of use cases. Here is an excerpt from Chapter 2 of a book excerpt I found online called "Microsoft Composite Application Block: A Framework for Building Smart Clients":

"The development model of CAB is centered around use cases that need to be fulfilled by an application. This paradigm lends itself well to User Centered Design (UCD) philosophy. The CAB artifact that embodies a use case is called a WorkItem. WorkItems provide means to aggregate and scope collaborating components that participate in a Use Case.

"Generally, you will find one to one correspondence between the primary use cases of your application and the WorkItems in your CAB application. A WorkItem can be thought of a container that binds all objects that are needed to implement a given use case. WorkItem manages the lifetime and scope of all collaborating objects it contains. All objects in a WorkItem have access to each other. Objects contained in a WorkItem have at most the lifetime of the WorkItem."

Here is a similar excerpt from the white paper/article "Architecting Composite Smart Clients Using CAB and SCSF," which I've encountered in different forms around the web:

"CAB is built for designing applications based on a use case–driven approach by clearly separating use case controller classes from views with their controller classes or presenter classes. ... Seen technically, a WorkItem is just a container for managing objects, which are required for accomplishing a certain task. Such objects are state objects, views and their presenters/controllers, or commands for launching an action. At a more high-level view, a WorkItem is a class encapsulating logic for one dedicated use case. It can be seen as a use case controller that knows all the different aspects of a use case. As such, a WorkItem holds state for all parts involved in a use case, such as views necessary to display, or sub-use cases. Furthermore, it acts as an entry point into the use case (or one of its sub-use cases) it is responsible for.

...

"As mentioned earlier, developing smart clients based on the Composite UI Application Block is very use case–centric. Therefore, it is crucial to start having a good understanding of your use cases (in the context of the client application). Primarily, there are three aspects that affect the development process for CAB-based smart clients: the Shell, infrastructure services, and the actual, detailed use cases."

FWIW, the full PDF I'm quoting from can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=5f9a8435-1651-4be2-956d-0446a89a7358&displaylang=en.

Given that my knowledge of CAB is based primarily on the research I've been doing (I've been doing quite a lot), these quotes might explain why I asked in my original post, "To what degree can we use CAB without worrying about the whole 'use case' aspect of CAB?" I still have that question, but I might at this point be in a better position to explain my concern relative to the importance of "use cases" in CAB and why there might be an "impedance mismatch" with MSFA's "scenarios".

First, on Microsoft Solutions Framework for Agile (MSFA) and Team System generally: for better or worse, and setting aside a long explanation/discussion that we could have on the merits of MSFA and Team System, we have adopted our own modified version of MSFA, and in our shop we are also adopting Visual Studio Team System (VSTS) and the Team Foundation Server (TFS). MSFA can be tightly integrated with Team System through the use of the "Process Template" and "Guidance Package" that Microsoft provides for VSTS. So when we're specifying a new project, we perform the initial activities according to the steps in the MSFA process:

  • Identify "Personas" (similar to Actors or Roles; see Alan Cooper's books and MSFA literature for more info)
  • Identify "Goals" that these Personas have relative to the desired system (example Goal: Find a Book to Read)
  • Identify "Scenarios" that apply to the fulfillment of each Goal (example Scenario: Find a Book Through a Keyword Search); Scenarios can also include "detailed requirements," including what MSFA calls "Quality of Service Requirements" (QoS)
  • Organize Scenarios into "Storyboards," which are mostly visual artifacts which, in a sense, put the Scenarios into action by illustrating wireframe "forms" and navigation flows (at this step, analysis and requirements activity starts transitioning into design activity).

The MSFA methodology is described as "Agile" because the idea is that a good deal of design is taking place concurrent with the requirements and analysis and programmers, theoretically, can start coding directly from the Scenarios and Storyboards, and the level of documentation is relatively compact. Team System ties this together by mapping "work items" to Scenarios and QoS requirements. (A tool called stpBA Storyboarding can take this even further by creating "Task" work items for each "form" that you model in the Storyboard.) Then when developers check in code elements to the TFS source code repository, their work can be tied back to the Team System "work items."

A key point in this context is the different levels of granularity of "use cases" and "scenarios." Setting aside some theoretical discussion about different ways to think about MSFA Personas, Goals, and Scenarios for different kinds of projects, we can say generally that a Scenario often turns out to be more specific, less expansive, than a use case. Alistair Cockburn in his Writing Effective Use Cases book describes use cases this way:

"The primary actor has a goal; the system should help the primary actor reach that goal. Some scenarios show the goal being achieved; some end with it being abandoned. Each scenario contains a sequence of steps showing how the actions and interactions unfold. A use case collects all the scenarios together, showing all the ways that the goal can succeed or fail."

Cockburn did not have MSFA Scenarios in mind when he wrote that, I'm sure, but his description is useful nonetheless: broadly speaking, a Scenario is a subset of a use case.

So what I've been trying to figure out is how serious this whole "use case" thing is inside of CAB.

<<< Evidently I've exceeded the maximum length for a post, so I'm moving the rest of this into the next post. >>>
Jul 12, 2007 at 11:25 PM
This connects in with the other areas my questioning: even if my use case concern turns out to be nothing to worry about, just how "composite" is the Composite Application Block? To put it another way, to what degree, or to what level, does the Composite Application Block "force" us into using dynamic composability of the system elements. I'll try to explain that...

By way of background, some of my fears about this are based on this description of the Composite Application design pattern from an article called "Composite Applications: The New Paradigm" this is linked from a few different Microsoft smart client landing pages:

"Composite applications offer a long-sought-after business nirvana whereby empowered technical business users can stitch together componetized business capabilities."

The composite application pattern interests us, but only to a point. The "composition" we need is not much more than we've all developed into every line-of-business app we've ever built: system "Roles" have access to some "modules" of the system, but not to others. From what it sounds like, we can use the CAB shell to dynamically load/download some modules (assuming, I would imagine, that modules are broken up into .NET assemblies) but not others, based on the user's "role." It sounds like the CAB Shell offers some other nice capabilities too, like window management and a shared menuing system. Sounds great, just what we need--but I don't think we need, or want, much more than that. "Composition" is not a particular requirement or design goal of our system.

At the risk of sounding sarcastic, we're coming to smart clients for their ability to free us from the woes of the traditional client/server model while still allowing us to create rich, fat client Windows applications; we are not seeking the "business nirvana whereby empowered technical business users can stitch together componetized business capabilities."

To put it bluntly, what I fear is that CAB's WorkItems and SmartParts are meant to steer us into a design like SharePoint's, in which have to think about all of our "parts" as little standalone pieces that can be dynamically composed based on configuration options. This is what I meant in my post above about "normal winforms"; I agree, Chris, with your negative impression of "normal winforms" as monolithic messes of code, and we share an assumption that MVP(C) is the way to go for presentation tier design. (Acknowledging that some "Views" are more complex than others.)

In this large, enterprise scope application we are designing goes way beyond CRUD screens that map to relatively simple entities or entities in simple header-detail relationships. We need the freedom, within CAB should we adopt it, to develop complex forms that implement complex information displays using grids, charts, sliders, tabs, and other visual elements that need to be managed in concert with each other. My fear is that the CAB framework might "get in our way" if we're trying to build a kind of application that's fundamentally at odds with the design assumptions of CAB.

It's possible that I'm missing something important because I have not adopted that same paradigm you have, Chris, so please help me out if I just need to shift my thinking somehow. I'm trying to keep an open mind.

Thanks again, Chris, for your valuable time (and for the work you do)--likewise to anyone else following along. Sorry for the long post.

Best,
Dan
Jul 13, 2007 at 2:51 AM


The composite application pattern interests us, but only to a point. The "composition" we need is not much more than we've all developed into every line-of-business app we've ever built: system "Roles" have access to some "modules" of the system, but not to others. From what it sounds like, we can use the CAB shell to dynamically load/download some modules (assuming, I would imagine, that modules are broken up into .NET assemblies) but not others, based on the user's "role." It sounds like the CAB Shell offers some other nice capabilities too, like window management and a shared menuing system. Sounds great, just what we need--but I don't think we need, or want, much more than that. "Composition" is not a particular requirement or design goal of our system.


The CAB will absolutely allow you to do what you just described. Modules are indeed assemblies. In fact, that was a point of confusion for a long time with many posters on this board; people didn't quite get that Module == Assembly == .dll. You can load modules (or choose not to load) based on user Roles. In our application, we take it a step further, and we configure controls and buttons based on user roles with a custom service we wrote.

I'm going to respond to this part next, because I get the feeling you and I are on the same page about this:


Composite applications offer a long-sought-after business nirvana whereby empowered technical business users can stitch together componetized business capabilities."


I don't consider "technical business users" to be programmers or developers, and I don't think they should be doing this sort of work (just like I don't think business users should be changing business "rules" . Business rules are code, and as such I feel they need to be tested just like any other production code).

Thus, I don't consider composition to be a "feature" in that sense. However, to me, it is a feature for a development team, because it allows developers to work in concert on small portions of the system and "compose" them together to fulfill a "use case". I like the fact that I can put a developer (or pair programming team) on a task to create a view that manipulates a subset of properties on a particular business object, and that when they are done with that View/Presenter pair of classes and have all their unit tests passing, I can plug their work in to the Controlling WorkItem that I'm writing for a use case and it will all work next time I compile and run it. I don't have to work on every single piece of a use case; I can just plug in pieces as team members get them completed. That is cool and powerful in my eyes, and to me that is one of the real values of composition.

Another comment here:


"The primary actor has a goal; the system should help the primary actor reach that goal. Some scenarios show the goal being achieved; some end with it being abandoned. Each scenario contains a sequence of steps showing how the actions and interactions unfold. A use case collects all the scenarios together, showing all the ways that the goal can succeed or fail."


I generally call this a Flow Chart :-) Other people use UML. I think the end result is the same: you're trying to determine the possible pathways the user will take for a given function/feature/use case.

I'm working on one of these right now: the ability to add a new Employee to our system. We're using a WizardWorkspace I wrote on Monday. We have two code paths: the data gets entered, validated at each step along the way, and finally (successfully) inserted into the system. Or the user cancels the action and the Wizard goes away. I can model that conceptually however you like, with a flow chart, UML, or just a conversation with a customer. This sort of thing is typically what I call a "use case".

That said: to me, "use case" is simply terminology. I think of "use cases" in a hierarchical fashion. For instance, one use case in our system is the ability to manage employee data. That's a very general, top-level use case. A lower level (sub) use case is more specific, like adding a new employee via the Wizard. Now, the literature you quoted refers to the WorkItem in CAB as the object that more or less encapsulates a "use case", and that is true (although you don't have to be confined by that definition), if you wish to think about it that way. But the cool thing is, if you do like that view of Use Cases, the WorkItems are hierarchical in nature, so you can nest them in an object hierarchy. This allows you to create use cases in a hierarchical fashion. We might start wth a top level WorkItem called "EmployeeWorkItem". Clicking on a menuItem or ToolStripItem may cause the EmployeeWorkItem to create a new AddNewEmployeeWorkItem, which then instantiates some views and shows the first one in a WizardWorkspace. When the AddNewEmployeeWorkItem is done (either succeeds, or the user closes it) then it goes away. The original, top-level WorkItem (EmployeeWorkItem) is still running, ready to handle the user clicking that menuItem or toolstripItem again, or ready for them to edit an existing employee, or ready for them to search for an employee.... You get the idea.

You can break down the use cases to whatever granularity you like. You could have one monolithic workItem managing every aspect of a huge use case, or you can break it up so child workitems manage specific aspects of a use case (scenarios in your terminology).

So if a "scenario" is a subset of a "use case" in your eyes (and this is all just semantics here from my perspective) then by all means, you can use the CAB "WorkItem" class to model that hierarchical nature.


"The primary actor has a goal; the system should help the primary actor reach that goal. Some scenarios show the goal being achieved; some end with it being abandoned. Each scenario contains a sequence of steps showing how the actions and interactions unfold. A use case collects all the scenarios together, showing all the ways that the goal can succeed or fail."


I don't think you sound any more sarcastic than I felt when I read that quote :=)

CAB, btw, can be used to build any kind of rich windows app; smart client or traditional client/server. Doesn't matter. We started out building a Smart Client (and maybe at some point in time a portion of our app will behave like a true Smart Client) but already it has morphed more into a traditional client server app. We still use web services to connect to our data, but more and more we're seeing needs to do things like duplex messaging, etc. CAB doesn't inhibit us from doing any of that, which is great.


We need the freedom, within CAB should we adopt it, to develop complex forms that implement complex information displays using grids, charts, sliders, tabs, and other visual elements that need to be managed in concert with each other. My fear is that the CAB framework might "get in our way" if we're trying to build a kind of application that's fundamentally at odds with the design assumptions of CAB.


Then your need is exactly like ours :-) And the CAB can help you do that. Features like the EventBroker allow for cross-view, cross-workItem communication so you can synch data and actions as necessary.

In our shop, we don't use simple POCO objects. In fact, our business objects are rather rich. Our collections are all custom, and inherit from a base class that allows them to be databound directly to grids. We use Manager classes to aggregate business objects together and provide methods for the manipulation of that data (for instance, we have an EmployeeManager object that has child objects of Employee, Departments, EmployeeStatus, EmployeePayRate, etc.)

CAB does not hinder us in any way from doing things in this way. I am not familiar with Sharepoint, but from the sounds of it CAB is nothing like that. You are free to create data any way you like and to display it however you like. The only thing CAB even remotely encourages is the use of MVP to separate the business logic from the display logic.


It's possible that I'm missing something important because I have not adopted that same paradigm you have, Chris, so please help me out if I just need to shift my thinking somehow. I'm trying to keep an open mind.



I think what this boils down to is simply unfamiliarity with what CAB actually does and how it can help you. And now that you've provided me with a huge wealth of information here I think I can safely say that a large part of your confusion probably stems from the amount of experience/knowledge you have with other tools (Sharepoint, etc.) I know for myself, when I see terms tossed around and overexposed so much from one tool/framework to the next, they don't always retain the same meaning and it can be easy to lose sight of what is really happening.

One of the strengths (and weaknesses) of the CAB, IMO, is that it is incredibly flexible and doesn't "force" you do do things in a particular way. How you compose your views, how you use WorkItems and Controllers and how you structure the design of your application will be entirely up to you and your development team. That is also the weakness; you have to know good design patterns in order to have CAB make use of them. I was not as well versed in good design when I started working with CAB two years ago. I have refactored our design in several spots over time as I and my team learn more and find better and more useful ways to accomplish things. But the whole time the CAB never stood in our way; if we needed to build smaller classes to break up the work being done by a Presenter, or if we needed to create complex view logic to display data in a way that our users demanded, we had the full flexibility of the .NET framework to do that with.

I'm at the character limit. Await reply


-Chris



Jul 16, 2007 at 1:05 AM
Edited Jul 16, 2007 at 1:09 AM
HI Daniel

Agreeing with everyting Chris stated above, I wanted to add a few more clarifications.

1. Agile dev.

CAB does not in any way prescribe a particular methodology. The RACON article describes usage in much more of a traditional waterfall approach i.e. lots of analysis up-front, etc. However CAB can certainly be used in an agile approach as well. For example, several of our MVPs use CAB in agile / scrum shops.
Because CAB at the heart is dynamic, you can evolve / refactor your application as requirements change. With CAB you are not building monolithic applications, but rather modularized components that are discovered and woven together at run-time. This means you can introduce new functionality into the system without having to rebuild it in entirely.

2. Workitem / Use case

Although often a WorkItem is described as representing a use case this is not set in stone. Many CAB users consider a WorkItem more of a hybrid correspoinding more to a 'story' rather than a single use case. It's up to you as to how and when you use it. This is one area where we have been a bit ambiguous.

3. UI Composability

As you mentioned, CAB has quite a bit of functionality designed to get a set of loosely coupled components to talk to each other and function as if they were had a more direct relationship. This manifests itself in our Smart parts, Workspaces, UI Extensions and Event Broker functionality. Smart parts are more than just about loose coupling to other smart parts, Smart parts are really controls that implement an interface that allows specifying information about how and where they are displayed (Smart Part info) as well as expose other aspects of CAB. You can still have tight relationships between them if you so choose though we recommend you don't if you want to gain the maximum benefit. However, if you don't need this level of composability, you don't have to use it. For example in the simplest case you can wrap a class that simply exposes the shell form to each of the modules as a CAB Service. Then you can add your own functionality to that class for handling how your UI components are displayed.

Hope this helps

Glenn Block
patterns and practices Client UX
Jul 16, 2007 at 7:16 PM
Chris and Glenn, thank you very much. This is exactly the type of information I was looking for. You have definitely reassured me that CAB is what we're looking for. I think what has made this difficult for me is a combination of a) the overall size and complexity of CAB and b) the fact that the literature out there about CAB is so caught up in describing the mechanics of CAB and touting the use-case-driven Composite Application paradigm that one does not get the sense that CAB is actually a wide open framework that can handle a wide range of application design scenarios (the RACON white paper is particularly scary in this regard, perhaps because it is so specific to their particular implementation). Complicating this further are the debates you can find out on the blogs about the learning curve associated with CAB and whether or not CAB is "too complex."

Learning curves and complexity are acceptable risks if the upside is high. My queries to you have been in part an effort to try to figure out what the upside is exactly. You have reassured me that the upside could indeed be very high, not only in the fact that we'll be able to handle the situations that will come up in our next application, but also the next ten applications.

I can see, though, that we're going to need to learn how to "think in CAB" when considering how to design a given set of functionality.

Regarding the SharePoint connection to all this: from where I sit, SharePoint is a "Composite Application" according to the definitions in the aforementioned "Composite Applications: The New Paradigm" article. Administrators (not developers) can configure modules and sub-modules that are composed on a per-user basis at runtime. Taking it further, within modules end users can configure the user interface to compose which "web parts" will be visible and how they will behave (kind of like the way you can customize a My Yahoo! home page to show certain "blocks" on the page--weather, news items, travel searches, stock ticker, etc.). Part of my fear was that CAB would force us to design our applications according to this vision of the "Composite Application" design pattern.

I should probably start another thread for this, but I'm intrigued by this snippet from your response, Chris:

In our shop, we don't use simple POCO objects. In fact, our business objects are rather rich. Our collections are all custom, and inherit from a base class that allows them to be databound directly to grids. We use Manager classes to aggregate business objects together and provide methods for the manipulation of that data (for instance, we have an EmployeeManager object that has child objects of Employee, Departments, EmployeeStatus, EmployeePayRate, etc.)
I'm familiar with this pattern. We use it often in our shop. I like to call it the Manager-State pattern. It has it's downsides (as all patterns do), but it's easy for most developers to get their head around. It sounds like maybe you have a "true client/server" design? Is that a correct impression? How middle-tier-centric is your application? Is the middle tier mostly just a pass-through to the database, with your Manager classes and business objects being primarily client-side entities, or do you have a good deal of business logic happening in the middle tier? Also, is your middle tier returning serialized objects that you hydrate and use directly in the presentation tier, or is your middle tier returning more "generic" data structures that are then loaded by your client-side Manager classes into "business objects"?

Thanks again,
Dan
Jul 16, 2007 at 10:48 PM
Hi Daniel

Although there are parrallels, the SharePoint paradigm is also very different. SharePoint is more about portals where a user picks the pieces (web parts) they want to see and arranges them in a suitable format based on their preferences. SharePoint offers the capability of defining such portals, and for laying out these components.

CAB on the other hand is for a much more static case. In a CAB app the parts on the screen are usually pretty static. What's dynamic is that the parts that remain static are composed on the fly. However, CAB is not designed for building user preference driven portals. It can support this functionality, but it is not the primary focus whereas in SharePoint it is. CAB's focus is more on how do you faciliate multiple teams of developers to work in isolation from each other, yet the shell brings the distinctive pieces (parts and modules) together at runtime in a coherent fashion and provides a defined route of communication between them.

Does this make sense?
Jul 16, 2007 at 11:14 PM

I'm familiar with this pattern. We use it often in our shop. I like to call it the Manager-State pattern. It has it's downsides (as all patterns do), but it's easy for most developers to get their head around. It sounds like maybe you have a "true client/server" design? Is that a correct impression? How middle-tier-centric is your application? Is the middle tier mostly just a pass-through to the database, with your Manager classes and business objects being primarily client-side entities, or do you have a good deal of business logic happening in the middle tier? Also, is your middle tier returning serialized objects that you hydrate and use directly in the presentation tier, or is your middle tier returning more "generic" data structures that are then loaded by your client-side Manager classes into "business objects"?


Answering in reverse order asked:

Our middle tier (which I kind of like to think of as the "service" layer, because have a facade over it, with a data access layer underneath it) does return serialized objects, yes. And we do bind their collections directly to datagrids in views (individual properties we map to view elements, so we don't pass whole business objects to views). Our service layer returns our business objects (most of the time the managers), fully baked, as I liked to say (or hydrated if you prefer the term :-)

We don't do any sort of DTO/Message wrapping and mapping or anything of that sort. Initially we were doing something like that, but found it really cumbersome. Then I read about the "wormhole anti-pattern" and that was enough to reaffirm my belief to just send the objects across the wire. I like the simplicity of one object type. And we can afford to do that because we have control over both sides of the wire; we control every piece of the server side code, and all of the client side code. Not every one is as lucky, so they have to deal with web services they can't control, objects they have to map to client side business objects, etc. I'm sure if we didn't have control of our web services and the objects being returned, we'd be forced to do something else.

Our "middle tier" is basically a service facade over our data access classes. We write proxy classes for the client to call to the webservice facade, and we expect to get back business objects or managers from those calls. So from the client perspective, our code looks like this:

EmployeeManager manager = _payrollService.GetEmployee(employeeID);

Inside our service layer we do have some business logic (the rest of the business logic resides in the manager classes themselves). We have strategy patterns that we write to perform certain algorithms, and we make service calls from the client to execute that logic and return altered managers or business objects, their states now changed.

For instance, we have a TimecardManager for the timecard portion of our application, and one of the things it needs to do whenever a user enters hours worked (or overtime, or comptime, or uses sick leave, etc.) is to calculate the overtime earned, if any, and make adjustment to the totals in realtime, because that's what our users wanted. So every time a user enters a new value the TimecardManager accepts it, then we make a service call to an OvertimeCalculator that runs a series of strategies to calculate overtime values and update the TimecardManger's entries. Different agencies calculate things differently, so we have to be able to dynamically run the strategies based on configuration. So we define an Interface for the strategies, and then using configuration (database, or XML) the appropriate assemblies get loaded and the strategies execute, and the results updated accordingly. Since we have different agencies that want different strategies (essentially different business rules) we don't want to deploy all of those, so that's why they get deployed server-side, and run when a service call is made.

The way it worked out was good for us and flexible for the different agencies we're dealing with, so we're probably going to do more of that sort of business logic provided the calls themselves don't degrade performance. I try and be aware of execution time and the number and size of data we're sending over the wire.

I hope that's what you're looking for :-)

-Chris

Jul 17, 2007 at 9:02 PM
Edited Jul 17, 2007 at 9:03 PM
Chris and Glenn, thank you (again) for your helpful followup posts. Chris, your information about how you are separating your presentation and middle tiers is exactly the kind of information I was looking for. I'm rolling around various architecture strategies, and it's helpful to hear how someone else is doing it, particularly using CAB.

Dan


Jul 23, 2007 at 8:19 PM
Chris -
Is the WizardWorkspace going to show up in the Smart Client Software Factory Contrib project?
Jul 23, 2007 at 8:45 PM
Chris -

I concur - this sounds like a perfect addition to the Contrib project. I have some development projects coming up where I'll need to do something similar, and it sounds like what you've done with a wizard workspace would cut down on my development time considerably.
Jul 24, 2007 at 1:06 AM

mfaulcon wrote:
Chris -

I concur - this sounds like a perfect addition to the Contrib project. I have some development projects coming up where I'll need to do something similar, and it sounds like what you've done with a wizard workspace would cut down on my development time considerably.


I very much want to include the WizardWorkspace in the Contrib project. I just need to refine it a bit; it's alpha code quality right now and there's a problem with tab ordering due to the way I wrote the code.

As soon as I refactor it and have it working the way it should then I'll pass it to the rest of the contrib members for review and hopefully it will end up in everyone's hands :-)

Aug 13, 2007 at 2:40 AM
Chris -

Any updates?
Aug 13, 2007 at 5:20 PM
The workspace works. I'm trying to get it integrated with the Contrib project, but having a problem merging my code. I hope to get the problem worked out shortly. If not, might have to post it to my blog instead.