Smart Client (SCSF) Membership App - Design

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 membership application is primarily about tracking and managing memberships in an organization such as a church or synagogue, small club or user group, sports team or league, etc. In the case of our church we need to track both individual persons and households. People may give us cell phone as well as home phone numbers and we mail our weekly newsletter to people who couldn't attend worship. Thus phone numbers can be associated with an individual person or a household and, of course, households have physical addresses for mailing purposes - we wouldn't mail two copies of a newsletter to a couple but rather one copy to their household address.

I chose "Contact" as the primary entity, e.g. something which we have contact with and derived both "Person" and "Household" from that base entity. This allows either a person or a household to have contact information associated with it and allows a household to have one or more locations associated with it, e.g. main address, winter address, summer vacation address. Here's a portion of the schema which represents these relationships:
 
One other interesting relationship is that one or more people are associated with a household and have a "role" in that relationship, e.g. husband, wife, daughter, son, etc. Thus, a single household contact is associated with one or more person contacts. It's these kind of sticky relationships that confounded me when trying to use Access' forms engine and event-driven data model where much of the magic goes on under the covers.

For manageability and future growth, I decided to logically bundle information and functionality into separate modules which I've identified as:

• Members
• Groups
• Events
• Reporting

Members is the foundational module upon which the others are built. Groups allows for dividing and tracking members in smaller units, e.g. youth group, men's group, committees, teams - assuming you're managing a whole sports league, etc. Events allows managing of date-related information, scheduling, tracking attendance, etc. Reporting is a bit of a catch-all for more complex information generation - each module should have limited print capabilities but reporting is a whole separate beast so to speak. Of course, SCSF uses the concept of modules - see link in first paragraph for overview of SCSF and its capabilities - so this type of decomposition fits naturally with the toolset.

Architecturally speaking, I have a set of goals I'd like to accomplish as well. The first is driven by commercial and market interests - I'd like the ability for the application to be downloaded and installed in a simple, standalone manner with minimum fuss. While I haven't decided yet, I can envision the possibility for shareware, trialware, or free editions that have a basic set of functionality. For me this means using an embedded database such as SQL Server 2005 Compact Edition or SQLite both of which have a very small footprint and can be deployed within the application without a lot of overhead. Can you imagine a pastor, part-time coach, choir director or quilting club chairperson having to install, configure and secure a full-blown database server on their computer not to mention the overhead it takes to run one?

At the same time, I need the ability to enable distributed management of information. Specifically, our church has two sites and two part-time administrative assistants who share duties. They both need access to the same data which means some type of remote capability so a hosted web service layer with a shared database behind it fits the bill nicely. Of course, when considering a remote model the notion of occasionally connected or disconnected clients must also be taken into consideration. Again, features which are provided for by SCSF.

As in many or most applications, there exists a common set of tasks which need to be repeated over and over. While the list of modules is varied, three of them share the common need to maintain information so I will focus on the Members module primarily.

Original post