At work, I'm developing a Flex intranet company newsletter application. One of the first parts of the application is a login for users. To document what I'm learning as I design this application, I'm starting a series of blog entries on creating a Flex application that uses a login system tied to a database backend to authenticate a user before showing the user the main application. I will start from scratch and post a series of articles on how I designed this login system.
To understand these blog entries you should be familiar with structured query language (SQL), ColdFusion MX, ColdFusion Components, Flex 2.0, and Flex Builder. My backend database for development is SQL Server 2005 Express and I use SQL Server Studio Managerment Express for database design and testing (both are free from Microsoft).
The main application for my personal testing is called Geek Newsletter. Since we are just concerned with building a login system for the main application, we don't need to worry about what the Geek Newsletter application will actually do. Please note my Geek Newsletter term should not be confused with any existing Geek News or Geek Newsletter applications, websites, etc.
Login Use Cases
I'm going to start with two very simple use cases.
A. User visits the application and the login screen loads. User is already a member. User enters user name and password correctly. User information is validated by comparing user information to information stored in a database. User supplied information matches what is found in the database. User is shown the main application.
B. User visits the application and the login screen loads. User is not already a member. User clicks on the join button. Login form changes to a registration form. User enters registration information correctly. User's information is stored in the database successfully. Registration form changes back to login form. User proceeds as in case A.
1. Database will store the following information about each member: userName, password, firstName, lastName, and email.
2. Every userName and email address must be unique.
3. Everyone must login to access the main application
4. Users who are not yet members may join by successfully completing a registration form that collects the information specified in business rule 1
Design Part 1 - Building the Backend
(Note: You can download all the code and SQL scripts. Unzip the files into a directory under your web root if you want to use the CFCs and test CF templates.)
Once I have a couple of simple use cases and business rules to work with, I like to start my design with developing and testing the backend. Based on the uses cases and business rules known so far, I've determined that I just need one table in my database. So in SQL Server Studio Management Express, I created a new database named GeekNewsDB. In that database, I created a new table called member. Below is the create table SQL (which is also part of the code download for this tutorial).
Create the Member table in database
A database named GeekNewsDB must have been already
drop table Member;
create table Member (
memID integer IDENTITY(1,1) primary key,
memUserName varchar(40) not null,
memPassword varchar(40) not null,
memEmail varchar(200) not null,
memFirstName varchar(50) not null,
memLastName varchar(50) not null,
CONSTRAINT memUserNameCon UNIQUE(memUserName),
CONSTRAINT memEmailCon UNIQUE(memEmail)
Notice that the primary key for table Member is memID and will be automatically populated by SQL Server. Also note that I've stated each column cannot be null and that the memUserName and memEmail must be unique. I am trying to get the database to help enforce some of the business rules noted above.
After creating the table, I wrote some SQL scripts to test constraints. That SQL file is part of the zip download.
To connect to the GeekNewsDB, you'll need to create a Data Source Name and connect it to the SQL Server 2005 GeekNewsDB database. I used GeekNews as my data source name. If you use a different name, you'll need to change the TestMemberDao.cfm file.
Next I created a Member.cfc, a MemberDAO.cfc, and a MemberService.cfc. These CFCs are standard ColdFusion practices to work with data stored in a table. You should note that my MemberDAO.cfc uses CFTransaction and throws exceptions if the database operations (Create, Read, Update, Delete) are not successfully completed. The files TestMember.cfm, TestMemberDAO.cfm, TestMemberService.cfm test these CFCs and also provide examples of how you could handle the exceptions thrown by the MemberDAO.cfc.
After passing the tests, I have some confidence that my backend design is working. I can now proceed to the initial design of the Flex front end, which will be the next tutorial.
(Note: you may be wondering why I did not provide a MemberGateway.cfc. Since we are not yet concerned with collections of Member objects I decided a MemberGateway.cfc was not needed.)
Please feel free to post comments about my code and design approach. If you've got some good ideas about improving what I'm doing please post and provide links to some other similar examples.