Smart Client (SCSF) Membership App - Members Module

This post is part of a series which discusses the journey I took building a smart client membership application using Microsoft's Smart Client Software Factory (SCSF). You can navigate the entire series by going to the introduction.

The Members module is typical of SCSF business modules - it encapsulates the presentation and UI logic of a related set of business functionality. For the membership application I'm building this means:

• People
• Households
• Contact Info (phone, email, etc.)
• Addresses
• Relationships between all of the above

Using the SCSF recipe to add a business module adds a new project to the Visual Studio solution as shown here:

I've highlighted a few key items to note:

• EntityLayer is the separate project containing the business entity logic and translators. This project is not directly referenced by the Members module. Refer to my previous blog post for more details.
• WebServices is a traditional web service layer which is currently referenced by the Members Module but will be replaced with a service layer enabling switching between local and remote databases.
• Members is the new business module and topic of this post.

Also, notice the views subfolder containing several views which this module manages. Here is an example screen shot which I've decorated to illustrate some of the various views in action:

The first thing to note is the menu option added to the shell application entitled "Members". The code for doing this is located in the ModuleController.cs file created by the SCSF recipe - the method ExtendMenu contains a "// TODO:" -like section for you to fill in as shown here:

The toolstrip (a.k.a. toolbar) partially hidden by the dropped down menu also contains icons for accessing People and Households functionality. The key concept with the menu and toolstrip comes from the nature of CAB itself - composite applications. The Members module contains functionality related to members and exposes it thru views and by extending the shell's infrastructure, i.e. menus and toolbars. When the Members module is loaded by the shell it "plugs in" this functionality by extending what's provided in the shell. Thus, the finished application is "composed" of discrete pieces that fit and work together as a whole.

Since the Members module added the menu options and toolstrip buttons, it also registers and contains the command handler to react when UI events occur, that is when either is clicked. When either the People menu option is chosen or the People toolbar icon is clicked, the command handler for that event launches the PersonListView which you see indicated on the left side of the screenshot above. Clicking on a person's name in the list view fires another event which triggers the PersonTabView to be displayed with the selected person's name on the tab as shown at the bottom of the screen shot. This tab view is currently a CAB Tab Workspace which I swapped in place of the default Deck Workspace which the recipe generates.

The PersonTabView currently contains additional views for the summary information as well as the contact information. Household works the same way but with household-specific information such as addresses.

This has only been a high level examination of the Members module. The next few posts will drill down into specific areas for deeper examination.

Original post