The User Class

I l @ ve RuBoard

The User Class

Let's begin by looking at the User class because the user/customer is usually the center of the application's purpose. What do you need to know about a user?

Obviously, the client will have information that he wants you to capture about the user ”things that aren't directly related to making the application work but that are important to the business model. For example, the fact that the customer's phone number is required doesn't really change the way the site works much in terms of design, but it can be critical for the business users from an operational standpoint. For example, they might want to call a customer if there is a problem with an order.

In addition to the client's requirements, you'll find the need for housekeeping attributes and other implementation-specific information that the client neither knows nor cares about. As the application development progresses, you will also find that you're discovering new attributes to add. That's okay; an ERD should be a living document until the code freezes before deployment. You always discover things you hadn't thought about when you start coding.

In an e-commerce site, you usually know what you need to capture about the user: name , address, telephone number, e-mail address, and billing information. This represents the bare minimum. This case would seem to lead naturally to the ERD shown in Figure 5.2

Figure 5.2. A simplistic view of the User class.

WHEN THINGS GET COMPLEX

The bare-minimum user schema is just that ”the bare minimum. I've worked on pharmacy sites that had to capture significant amounts of medical information about the customer. Everything from the physician 's name to drug allergies and current prescriptions needed to be captured, in multipage forms with all sorts of validations and cross-checks.

I've also done insurance sites with more than 300 pieces of information being captured on a single, compact enrollment form. In this case, things were a bit easier because I had the paper form to use for comparison. In fact, it was a requirement that the online form match the paper version as closely as possible.

It's critical that you get the data set correct the first time. It's somewhere between difficult and impossible to get a piece of data after the customer has already been to the site and gone. A good set of use cases should include this information.

The data set that you need to capture for a customer, however, is a bit more complicated than it might seem. For one thing, most e-commerce sites (including this one) allow you to ship a purchase to one address and bill it to another address. This would require the class to look more like Figure 5.3.

Figure 5.3. Things get complicated for the User class.

Not only is the User object quickly filling with attributes (and you haven't even begun to add those that will be needed for application housekeeping), but even this design for the User object won't handle your needs because you allow multiple shipping addresses to be stored with the user in an address book, and multiple billing addresses to be stored with the user in his wallet of credit cards (each credit card has an associated address.)

To make multiple addresses work, you need to break addresses as well as credit cards into their own object classes. Credit cards, in turn , point to address objects as well. This leads to the ERD shown in Figure 5.4.

Figure 5.4. The User class and associates .

The Customer class has been reduced to the bare essentials: last and first name of the customer, e-mail address, and arrays of addresses and credit cards. Credit cards also use the address object, but because this object stores only last name and first name for an address and some credit cards require a middle name or initial, the name on the credit card is stored explicitly rather than using the name fields of the address.

It should be noted that this design will work only for customers in the United States. For international use, you would need to add fields such as Country and make sure that you allowed enough space for non “U.S. telephone numbers and postal codes. Frankly, very few e-commerce sites are prepared for the numerous headaches associated with international business anyway; details such as shipping, tariffs, and taxation get very complicated in international cases.

You might also consider using more internationalized names for variables , such as givenName rather than firstName . This can be confusing for developers, however, and I'll wager that many U.S. developers couldn't tell you what a "given name" was, but they'd all know what a first name was. If you're going to be mapping to LDAP (see Chapter 15, " Using LDAP with JNDI"), you're going to end up having to use terms such as givenName anyway because those are the names used in the standard LDAP schema.

Still a lot of details are left to explore at this point, especially in regard to how this data will actually be stored in the database. This gives you enough information to continue, though.

I l @ ve RuBoard