The most important step in developing an application is design. Without a proper design, things can get very hairy later down the line. Spending one minute at this stage saves you ten minutes during development. Therefore, before you start development, you must lay down a solid foundation in design schemes and have a plan of attack.
The BananaMobile application will use a three-tier approach (see the "Why Use Components" section of Day 15, "Using Business Objects"). You'll have the data stores in the back end, a layer of business objects to interact with data and perform operations will be in the middle tier, and of course, the user interface will be developed in ASP.NET in the front end. The next few sections examine each of these tiers, and lay out what needs to be accomplished in each.
First, let's analyze the back end and data stores required for the site. Obviously, this application is going to require a database. Specifically, you'll need to keep track of four things: customers and their information, orders, BananaMobile parts and information, and data posted from the BananaConnect system.
The information that BananaMobile, Inc. keeps for customers is fairly standard, so you can simply use a version of the user database developed in Day 8, "Beginning to Build Databases." This database includes information such as names, contact information, site username, and password.
When keeping track of customer orders, you'll need to store information on who ordered items and what exactly was ordered. Because the site allows users to completely customize their BananaMobile configuration, each order can be different. You'll need to make sure that this information is accurately tracked. Therefore, you'll have one field for each of the customizable types, as well as a price field that contains the running sum of the parts ordered.
The BananaMobile parts and information data will be fairly straightforward. After consulting with BananaMobile, Inc., you've determined that there are six different customizable parts: wheels, color of the banana, engine, the patented BananaThrowing system (the BTS, used for competitions), the type of base frame of the vehicle, and interior carpet. Each customizable item will have an associated price and description. You'll build one large table that will hold all the items, making sure to group each by category.
The data posted from the BananaConnect system contains only mileage, throttle, and max speed information, so this can be kept in a simple table.
Finally, the shopping cart information (see "The Banana Front End" section later today) will be stored in the database, so you'll need a table to hold temporary information while users are browsing. This table simply holds the customer ID and a part ID for each of the customizable parts; everything else can be pulled from one of the other tables. This table will be a temporary version of the orders table; when a user places the order, you'll move the information from this temporary table to the orders table.
You'll also create a variety of stored procedures. However, until you know the functionality needed by the front and middle layers, you won't know for sure what procedures to create. From analyzing the data so far, you know that you'll need procedures to accomplish the following tasks:
Validate a user's credentials
Add users to the customers table
Retrieve and add information to the shopping cart table
Retrieve information from the customizable parts table
Move information from the temporary shopping cart table to the permanent orders table
Add information to the BananaConnect table
You'll get back to this later.
After analyzing the data requirements, you'll end up with something similar to Figure 22.2. There will be four tables holding the different categories of data discussed earlier orders, parts, shopping carts, and BananaConnect information and a user table. In addition, the orders and user tables will be related (each order needs to be linked to a particular user). Also, the shopping cart table will be linked to the user table. The BananaConnect table will need to be related to the user table, so only registered users are allowed to post information.
Figure 22.2. The data relationship diagram.
Note that this diagram isn't the end-all of the design. In fact, it leaves out many of the fields that you'll require for your application (I'll discuss those later today). This diagram is merely meant to provide a simple illustration to get you started building. It can be changed easily, but it presents you with a very good vantage point when you start development.
The Banana Front End
The requirements for the UI are derived directly from the requirements given you by BananaMobile, Inc. You'll need a shopping-type interface, so that users can browse through BananaMobile parts and add selected items to their shopping cart. The difference between this functionality and shopping carts on other sites is that yours will be used to assemble a BananaMobile, rather than holding a collection of unrelated items. Therefore, users should be allowed to add only one of each item; subsequent additions will replace existing components. Additionally, only registered users should be able to purchase or add items to their shopping cart, so you'll need a login page and a registration page to add users to your database.
You'll also need a page for users to check out and actually purchase their completed BananaMobile. Note that you're not going to build a place for collecting payment information such as credit card numbers just assume that customers have valid account information.
You'll also have to build a Web service that allows data about the BananaMobile's automotive performance to be posted. This service will take the automotive performance data and insert it into the database. Naturally, you'll want only registered BananaMobile users to post information, so you'll have to secure the service as well.
You'll incorporate several user controls into the application, which will display common pieces of the UI, such as headers and footers. The use of user controls will make development go faster and more smoothly. Also, user controls will be invaluable because you want to present a consistent user interface across all pages in your site.
Let's recap the pages you'll need:
Product browsing page
Shopping cart page (allows users to view and remove items in their cart)
Checkout or purchase page
A default or home page (every site needs one of these)
At least two user controls: a common header and a common menu/navigation bar
Banana Business Objects
Recall from Day 15 that business objects are reusable pieces of code that can be plugged into your applications. They often represent real-world objects and encapsulate commonly used code so that you don't have to worry about the additional complexity or extra code. You'll be using two business objects in the BananaMobile application.
As you are probably already aware, a BananaMobile is an ideal candidate for representation as a business object. The BananaMobile business object will contain the functionality to add and remove parts, as well as keeping track of which parts a BananaMobile-in-progress contains. Because all this data will be stored in the database, this object's methods will utilize stored procedures.
You'll also build a business object used to represent a customer. This site will require a secure logon to purchase a BananaMobile, and this object will provide the methods to validate users and retrieve their information.