The SCSF contains a wizard for generating the projects that comprise a CAB application. After installing the SCSF and its associated utilities, you see the Guidance Packages item in the New Project dialog box in Visual Studio. The Smart Client Development item underneath it contains a template named Smart Client Application, as shown in Figure 2-1.
The SCSF needs to know the location of the CAB dynamic linked libraries (DLLs) and of the Enterprise Library DLLs because it uses both in its generated code. It prompts you for them using the box shown in Figure 2-2. You also need to enter the namespace to be used for the classes in your generated project.
Note
| Not all SCSF project developers like using the Enterprise Library in their CAB programs. You can actually remove it quite easily from the code generated by the SCSF if you want. Just open each generated project and remove the references to the Enterprise Library DLLs. Then compile the code and see where the errors are. There are only about three locations in which you'll have to remove EntLib code, generally relating to exception handling. Just make sure you put in your own exception handling in its place and don't just leave it undone. |
The SCSF generates four or five projects containing many files for a complete CAB application. Figure 2-3 shows the Visual Studio Solution Explorer displaying the results of such a generation. I will now discuss the purpose of each of the projects that you see.
The Shell project, as we've seen, is the main outer container of the application. It contains classes for the shell application and the shell form. It also contains the app.config file used by most .NET applications, and a ProfileCatalog.xml file used by the default module enumerator service, which we meet later in this chapter.
The Infrastructure.Module project builds a DLL that is loaded by the module loader service when the project starts up. It creates a child WorkItem, which it adds to the WorkItem chain. Most CAB applications contain several modules that can create a WorkItem, so one of the reasons that the wizard generates this module is to demonstrate how it's done. A production application would probably use an infrastructure module to contain its own services and other resources rather than clutter up the shell project with them.
Module項目編譯了一個(gè)DLL，當這個(gè)項目啟動(dòng)的時(shí)候通過(guò)Module Loader Service加載這個(gè)DLL。它生成了一個(gè)子的WorkItem加入WorkItemChain中。大部分CAB Application都包含了幾個(gè)Module，他們都能生成WorkItem。所以向導生成這個(gè)Module的原因是說(shuō)明Module如何運行的。 一個(gè)生產(chǎn)的Application應該使用一個(gè)infrastructure module來(lái)包含自己的服務(wù)和其他資源，而不是和Shell Project放在一起。
The Infrastructure.Library project contains the implementation of services that the SCSF adds to a CAB project. The action catalog service, which I discuss in Chapter 7, is an example of this sort of service. This DLL is generally deployed with the shell project and managed by the infrastructure team.
Libray項目包含了SCSF添加到CAB中的服務(wù)實(shí)現。Action Catglog Service，7章有個(gè)這個(gè)Service的例子。這個(gè)DLL一般和Shell項目一起部署，并由infrastructure team 管理。
The Infrastructure.Interface project contains the definitions of service interfaces, as distinct from their implementations. For example, it contains the definition of the IActionCatalogService interface, which is implemented in the Infrastructure.Library project I mentioned in the preceding paragraph. It also contains the implementation of certain core classes that we want all projects to use, such as ControlledWorkItem. In this sense, you might consider it a part of CAB 1.1. It also contains the definitions of string constants used for indexing many of the WorkItem chain's collections. This centralizing of string names avoids bugs and collisions later. You distribute this DLL to all development teams in the CAB project. This is the one piece of code that the developers actually do share, so you want it to be as sparse and as generic as possible—hence the inclusion of interface definitions rather than class implementations.
Interface項目包含了Service Interface的定義，和它們的實(shí)現區別開(kāi)來(lái)。例如，他包含了IActionCatalogService 接口的定義，這個(gè)接口在Library項目中實(shí)現。他也包括了我們想所有項目都使用的核心類(lèi)，例如ControledWorkItem。他也包括了一些字符串的常量定義，用來(lái)索引WorkItem Chain集合。這個(gè)集中字符串名字的做法避免了錯誤和沖突。你分發(fā)這個(gè)DLL給所有開(kāi)發(fā)團隊。這是開(kāi)發(fā)者真正共享的一部分代碼，所以盡量使他松散和一般化，因此包括了接口的定義而不是類(lèi)的實(shí)現。
The Infrastructure.Layout project is generated when you select the Create a Separate Module to Define the Layout for the Shell check box in the SCSF Wizard. If you don't select this box, then the layout of the user interface will then live directly in the shell project. The Infrastructure.Layout project will not be generated, and the shell form will contain a menu, status bar, toolbar, and two workspaces. If you do select the box, then the shell form will contain only one workspace that covers its entire surface. The Infrastructure.Layout DLL will contain a Smart Part (also known as a view) called the Layout View. This view will contain all the UI elements that the shell previously had and automatically place itself into the shell's workspace at startup time. You make this choice when you need several different shell form layouts for different configurations of the program. For example, suppose that client A wants its customer selection on the left side of the shell form, but client B wants its customer selection on the top of the shell form. The loose coupling mechanism of CAB allows you to create two or more separate Infrastructure.Layout modules and load one or another at runtime according to configuration files. This allows you to separate layout and program implementation, with a great increase in program flexibility. If, on the other hand, you are a corporate developer building a program solely for in-house use, you might not want to take the trouble of separating these concerns.
LayOut Project，在向導中選擇單獨生成才會(huì )有。否則，用戶(hù)接口的layout將和shell 項目在一起，shell form將包括僅有一個(gè)workspace。 LayoutDll包括一個(gè)Smart Part，被稱(chēng)作Layout View。這個(gè)View包括所有的UI elements. 你可以有多個(gè)Layout，可以在運行時(shí)加載其中的一個(gè)。
聯(lián)系客服
