Introduction
The latest version of the Smart Client Software Factory (SCSF) has recently been released. In order to become familiar with the new version, I have taken the reference example of the CSLA framework and converted the Windows Forms solution to use the SCSF. But first some background.
The SCSF is a powerful framework which I have used successfully for some time – see SuperSec. The latest version of the framework contains some new features and I wanted to see how they worked. For all its power, the SCSF is not for the faint hearted. The learning curve is very steep, but once you are there, it is very easy to use and very effective.
The CSLA framework is a very handy way to build a client server application with mobile objects. A number of people have raised the issue of using the SCSF with CSLA in the CSLA forums, and the response has been that the two match well. But anyone wanting to work out how to use the CSLA with the SCSF was on his own.
So this paper attempts to show how the Project Tracker (PT) example can be converted to run using the SCSF.
Background
Now for the warnings! Rockford Lhotka who has developed the CSLA framework is an extremely bright and able developer. His PT example is a very nice example of the way to write a smart client application. I'm not sure that the SCSF adds a lot to the example. But of course, all we are attempting to do is show how to use the SCSF!
In addition, the SCSF brings with it a lot of overhead – a lot of overhead! The PT example looks particularly silly. A great deal of code to do not a lot! The recent debate on the use of CAB and SCSF has been very informative but in my opinion, the SCSF is a valuable tool, and I for one will stick with it until Acropolis is with us.
The rest of this paper describes the steps to convert the PT example to use the SCSF. If you haven't downloaded CSLA (and the ProjectTracker
example), do so now. If you install the ProjectTracker
example, then the database will be set up for you.
Using the Code
The source code is contained here.
The following is the way to duplicate it.
Step 1 – Create a SCSF Project
Clearly you need to have the May 2007 version of the SCSF installed.
Create a new SCSF application and call it SCSFProjectTracker
. This creates a fully working smart client solution. Compile it and run it!
Step 2 – Add the Infrastructure.UI Module
The SCSF supplies most of what we need for the PT application. However the PT application makes use of modal forms. The SCSF reference implementation contains a useful module - Interface.UI
– which provides the functionality we require. Simply copy this module and change the namespace.
Step 3 – Change the Layout Module to Match the PT MainForm
There is no Menu strip in the PT example – so delete it, and remove the reference to _mainMenuStrip
.
Copy the ToolStrip
from the PT MainForm
to the ShellLayoutView
, delete the existing ToolStrip
, and rename the one you copied _mainToolStrip
.
Delete all the ToolStripItem
s from the drop downs for Projects, Resources, Admin, and Documents. Register the Projects, Resources, Admin, and Documents drop downs and the Login label and button in the ShellLayoutViewPresenter OnSet
method. Then add a command handler for the Login button.
Finally remove the LeftWorkspace
from the SplitContainer
, delete the SplitContainer
, and dock the LeftWorkspace
in the LayoutWorkspace
. Rename it to _mainWorkspace
.
In order for the application to compile, you will need to set the names in the UIExtensionNames
, WorkSpaceNames
, and CommandNames
classes.
Add two Event Handlers for SetStatusBusy
and CancelStatusBusy
to the ShellApplicationLayoutPresenter
.
Add two EventHandler
s for DocumentActive
and DocumentClosed
so that when a Project or Resource is being edited, you can move easily between the views.
Add a reference to the Intrastructure.UI
project, change WindowsWorkspace
to WindowsWorkspaceExtended
in the Module
class, and register the modal workspace.
Finally create a service – ShellNotificationService
– in the Infrastructure.Library
module. This implements the IMessageBoxService
and gives a unit testable way to provide message box functionality in your business modules. Register the service in the Infrastructure.Module
.
Now all the UI elements you need are available to your SCSF business modules.
Compile and run the application.
Step 4 – Add the ProjectTracker.Library and CSLA references
To make the business objects available to the UI, copy ProjectTracker.Library.dll and Csla.dll to the Lib folder of the solution. Now when we require references to the business objects, we can get them from one place. The best way to get access to the ProjectTracker
functions and to manage interaction with the database is to create a service.
Create a service ProjectTrackerService
in the Infrastructure.Library
project. This service implements IProjectTrackerService
in the Infrastructure.Interface
project so that it is available to all modules. Register the service in the Infrastructure.Module
.
Step 5 – Add the LoginModule
The first business module you need is one to manage user login.
Add a new business module - LoginModule
(without an Interface module).
The only view needed for this module is the LoginView
. Add a LoginView
using the SCSF Add View recipe. This is where the fun begins. The LoginView
consists of three partial classes – LoginView.cs, LoginViewDesigner.cs, and LoginView.GeneratedCode.cs. We also now wish to separate out business logic from code which is strictly needed in the UI.
The login process is treated as a separate Workitem
and managed by a LoginController
. Again this is probably a bit of overkill but it provides an easy way to create a view and then dispose of all the resources which were used. Typically a User will log in once and this ensures that resources which are not used in the remainder of the session are not left hanging around.
Some points to note. When the user logs in or logs out, and event is fired to let other modules know that the logged in state has changed. The PT example uses a StatusBusy
object to display a message in the status strip when database operations are taking place. This is replaced by firing an event when the database operation begins and when it ends.
The LoginView
is displayed when the application starts (triggered in the AddViews
method in the ModuleController
), and when the User clicks the login button.
Step 6 – Add the ProjectModule
Add a business module using SCSF – the ProjectModule
.
First add the ToolStripMenuItems
to the Project ToolStripDropDown
and register the elements and the commands in the ModuleController
. To ensure that the ToolStripMenuItems
are displayed correctly, add an ActionCatalogService
and register a general action condition ProjectActionCondition
. This ensures that the correct label is displayed and the menu items are enabled and disabled as appropriate. The ProjectActionCondition
is triggered when the Login and Logout events are fired.
There are two views in this module – the ProjectSelectView
and the ProjectEditView
. In the same way as we did with the LoginView
, create the two views using the SCSF recipes and transfer the code across from the PT sample.
The ability to select a project is needed in other modules. The best way to provide this capability is using a service ProjectSelectService
. Create a service IProjectSelectService
in Infrastructure.Interface
and provide an implementation in Infrastructure.Library
. Load the service in the ModuleController
.
IProjectSelectService
provides the methods to create a new project, edit an existing one or delete a project. This is the best way to make the ProjectSelect
capability available to other modules.
Step 7 – Add the ResourceModule
Add a business module using the SCSF – the ResourceModule
.
Creating the Resource functionality is similar to the process used in the ProjectModule
.
Step 8 – Add the Assign Functionality
Now that both the ProjectSelectService
and the ResourceSelectService
have been created, the Assign Resource and AssignProject
functionality can be added in ProjectEditViewPresenter
and ResourceEditViewPresenter
respectively.
Step 9 – Add the AdminModule
Next, add the AdminModule
. This provides a single view – RolesEditView
.
That's it. It's not difficult to do and it certainly shows the value of the SCSF and the CAB. I was able to test the modules independently, and if we wished to add more functionality, we can work on the appropriate Module on its own.
To run the example, use the user names and passwords – pm and pm, and admin and admin.
Points of Interest
The overhead associated with the CAB is really only obvious when the application loads. The original ProjectTracker
application starts almost immediately while the SCSF version takes a few seconds. Thereafter like most smart client applications, the difference is not noticeable.
History
- 26 June 2007: Application published