A fully functioning DB application

Introduction

The purpose of this example is to provide a simple but fully functioning customer management application, and also to exposing all basic concepts of WebMC Framework we discussed until now:

• Controller
• Models
• Views
• Templates
• OOP
• Placeholders and Blocks
• MVC Assembly
• Database and ORM

System Requirements

The Systems Requirements of our system are the following:
A generic application user must be able:

• To store, manage, and retrieve information about customers. The information must be about the name, email, nationality (Italian or guest), and assurance level (low, middle or high) of any given customer;
• To browse customers list
• To select a customer from the list for showing, editing its data or, eventually, delete its record from the DB
• To select a customer from the list for rapidly sending a mail
• To add a new customer record to the DB

System Design

We organized the System Design under the following sections:

Database Design

First of all, we need to define the Database Design to store and manage customers. In our system it is very simple, it consists of the single table customer coded below:

--
-- Table `customer`
--
CREATE TABLE `customer` (
  `customer_id` int(11) NOT NULL,
  `name` varchar(45) NOT NULL,
  `email` varchar(100) NOT NULL,
  `nationality` varchar(4) DEFAULT NULL,
  `assurance` int(1) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- PK for table `customer`
--
ALTER TABLE `customer`
  ADD PRIMARY KEY (`customer_id`);

--
-- Unique index for email field
-- 
ALTER TABLE `customer` ADD UNIQUE(`email`);

--
-- AUTO_INCREMENT for table `customer`
--
ALTER TABLE `customer`
  MODIFY `customer_id` int(11) NOT NULL AUTO_INCREMENT;
COMMIT;

As you can see in the SQL code above, the customer table stores the name, email, nationality, and assurance level (listed in system requirements). It also defines an incremental primary key, required by [DB normal forms](https://en.wikipedia.org/wiki/Database_normalization regarding no duplicate tuples), and a Unique index for the email field (** a Non-Functional Requirement**). Note that, when building a database, you should always be compliant with DB design principles.

GUI Design

Due to the simplicity of the system, we made a rapid "System Analysis" for establishing its GUI Design capable of covering all previous system requirements. So, we decided to provide two user scenarios, or better two web pages, for the purpose.

• One for providing the customer's list, from which the user should be able to select a customer for editing it's data or, also, adding a new one.
• The second for providing the showing or editing of a customer record previously selected, as well as to delete it, or for insert data regarding a new one.
  The following figures show you the GUI for these pages:

The left side showing the GUI for browsing customers with the ability to select a customer record for editing, or sending a mail easily. There is also a function to add a new record. The right side showing the GUI for a customer record. The same GUI can be used for implementing two different operative mode can be done on a customer record. The first, in the upper left, is regarding the editing mode where the user can show and update data, or delete a customer record previously selected. The second, in the bottom right, is regarding the inserting mode when the user needs to add a new customer to DB. Under a UML point of view, the right side may be considered as a single Use Case, the customer record, that can be extended with two different features: one regarding inserting, other for editing data.
In conclusion, we need the following two GUI templates:

The first template, on the left, is used for implementing the browsing, the second, on the right, for the customer's record. In the last one, both the insert and editing functions are implemented as extensions of the shared data form fields. Furthermore, all templates are provided with a responsive design (look, for example, at the navigation bar).

Application Design

Finally, we provide the Application Design to organize the Implementation of the system, by using two Web MVC Assemblies:

• CustomersManager for browsing customers and
• CustomerRecord for customer data manipulation.

Because the system is very simple we do not have the need for any Subsystems Design