SCSF - Part 2 WorkItems

Introduction

In part 1 of this article I introduced a simple example of how to use Microsoft’s Composite Application Block. To try to keep the example as simple as possible I only covered modules and shells.

There are two other core concepts that you need to understand to be able to use even the most basic functionality of the CAB. These are WorkItems, and dependency injection. This part of the article will discuss WorkItems, and part 3 will discuss dependency injection.

在第一篇文章里，我介绍了一个很简单的例子 如何使用微软的cab， 为了使这个例子尽可能的简单，我只涉及到了modules和shells。

现在还有两个核心的概念你需要理解从而去使用cab最简单的功能， 它们是workitems，和依赖注入，这篇文章 会讨论workitems， part3会介绍依赖注入。

 

WorkItems – Basic Concepts

Microsoft’s documentation defines a WorkItem as ‘a run-time container of components that are collaborating to fulfill a use case’. In many ways the best way to think of them is as classes that contain collections of other classes that are logically grouped together. The name is a little strange: ‘work items’ in general tend to be individual tasks that need to be performed in, say, a workflow, or, in the .NET Framework, in a thread pool. The WorkItems in the CAB are broader than that.

微软的文章定义了workitem为一个 可以实现usecase的运行时的容器组件， 在更多的情况下， 最好的理解是，拥有其它class集合的class被逻辑上放到了一个组里。 它的名字有点奇怪，‘workitem’ 在正常情况下会被认为是具有不同的需要被执行的任务集合，这个名字比较模糊。

 

In code terms WorkItems are just objects of type ‘WorkItem’ (a class in the Microsoft.Patterns.CompositeUI library). Each WorkItem has collection classes associated with it to allow it to ‘contain’ components. Three of these collection classes that are reasonably easy to understand are:

1. The Items collection, which can contain almost anything since it’s a (special) collection of System.Objects
2. The Services collection, which is a collection of CAB services.
3. The WorkItems collection, which is a collection of other ‘child’ WorkItems.

关于workitems 它们是workitem这个类的 objects们，每个workitem 下都有 collection classes 可以包含一些组件， 以下三种 collection classes 比较容易被理解

     1.  item collection,  可以包含任何东西，因为他是一个 （特殊的）system.objects的集合。

     2. services collection, 他是cab services的集合。

     3. workitems collection 他是其它 child workitem的集合。

 

However there are several other collections of CAB code objects on the WorkItem class. WorkItems also have state (used to track changes), and status (active/inactive).

然而我们还有其他一些cab object 的 collections， workitems  也有state（用来追踪变化）和status。

 

Container Hierarchy and the Root WorkItem

There’s a second important aspect of WorkItems: they can be arranged into a hierarchy. This hierarchy typically starts with a root WorkItem that contains components (code objects) and other WorkItems, the other WorkItems again can contain components and other WorkItems, and so on.

workitems还有一个第二重要的方面， 它们可以被安排成等级状的结构， 这个等级结构就有一个root workitem开始 rootworkitem可以含有其他workitems 然后其他workitem是又可以再含有他的子workitem。

 

This is particularly useful since we can construct the hierarchy across modules, even though the individual modules may not reference each other. We can then use the WorkItem hierarchy to use components in other modules.

这是特别有用的因为 这个树状结构连接了modules，即使不同的modules也许并不相互引用，我们可以使用这个workitem的 树状结构去使用其他modules里的组件。

 

I’ll show exactly how this works in a minute, but in our example from part 1 we could add a WorkItem class to each of our three projects. We could then instantiate one WorkItem object per project at runtime. The WorkItem object in the Shell program could be a root WorkItem. It could contain the other two WorkItems.

我将马上展示这是怎么奏效的， 但是在part1的例子里，我们可以在这三个项目里加一个workitem 类，他会包含其他两个workitem。

 

If we add a component from the Shell project to the root WorkItem we can access that from, say, the Red application’s WorkItem by simply using this.ParentWorkItem.Items[“ComponentName”].

如果我们加了一个组件在shell项目里的root workitem里，我们可以从红项目里通过简单的 使用 this.parentworkitem.items["componentname"]访问它。

 

One obvious difficulty with this approach is that we are then tightly-coupling our two modules together to some extent, which is what we were trying to avoid by not having direct dependencies between our modules. However, as we’ll see we can still release new versions of each module independently of the rest of the code.

这个方法的一个比较明显的困难是我们在一定程度上将两个modules给紧紧地耦合起来了，这是我们一直都想要避免的。但是我们仍然可以通过剩下的code独立的发布这些module。

 

 

WorkItems and the FormShellApplication

In part 1 of this article we saw that to start a CAB application we inherit from FormShellApplication<,>. We provide two types when we declare the new class to close the generic definition:

    public class Program : FormShellApplication<WorkItem, Form1>      {

As we have seen the second of these (Form1) is the shell for the application and gets instantiated and shown at start up (when we do new Program().Run()). The WorkItem also gets instantiated at start up. This will be the root WorkItem for the application, sitting at the top of the hierarchy described above. It can be referred to in the Program class using the RootWorkItem property (this.RootWorkItem).

在part1 我们知道启动一个cab的应用程序 我们需要继承 fromshellapplication，当我们声明新的class时，我们提供了两个类型来完成这个泛型定义，第二个是我们shell里的主form，第一个就是rootworkitem了。它将是所有workitem的根item。 可以在program 这个class里 使用rootworkitem 这个属性。