【文章內(nèi)容簡(jiǎn)介】 ESTAMP, `remark` VARCHAR(100) NULL, `image` VARCHAR(45) NULL, PRIMARY KEY (`id`)) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_general_ci CREATE TABLE IF NOT EXISTS `onlineorderfood`.`food` ( `id` INT NOT NULL AUTO_INCREMENT, `food_name` VARCHAR(45) NOT NULL, `price` INT NOT NULL, `image` VARCHAR(45) NULL, `seller_id` INT NOT NULL, `created_time` TIMESTAMP NULL DEFAULT 39。CURRENT_TIMESTAMP39。, `updated_time` TIMESTAMP NULL, `is_delete` INT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), INDEX `fk_food_user_idx` (`seller_id` ASC), UNIQUE INDEX `food_name_UNIQUE` (`food_name` ASC), CONSTRAINT `fk_food_user` FOREIGN KEY (`seller_id`) REFERENCES `onlineorderfood`.`user` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_general_ci CREATE TABLE IF NOT EXISTS `onlineorderfood`.`order` ( `id` INT NOT NULL AUTO_INCREMENT, `created_time` TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, `buyer_id` INT NOT NULL, `seller_id` INT NOT NULL, `phone` VARCHAR(45) NOT NULL, `adress` VARCHAR(100) NOT NULL, `remark` VARCHAR(100) NOT NULL, `is_delete` INT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), INDEX `fk_order_user1_idx` (`buyer_id` ASC), INDEX `fk_order_user2_idx` (`seller_id` ASC), CONSTRAINT `fk_order_user1` FOREIGN KEY (`buyer_id`) REFERENCES `onlineorderfood`.`user` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `fk_order_user2` FOREIGN KEY (`seller_id`) REFERENCES `onlineorderfood`.`user` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_general_ci CREATE TABLE IF NOT EXISTS `onlineorderfood`.`order_food` ( `order_id` INT NOT NULL, `food_id` INT NOT NULL, PRIMARY KEY (`order_id`, `food_id`), INDEX `fk_order_has_food_food1_idx` (`food_id` ASC), INDEX `fk_order_has_food_order1_idx` (`order_id` ASC), CONSTRAINT `fk_order_has_food_order1` 12 FOREIGN KEY (`order_id`) REFERENCES `onlineorderfood`.`order` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION, CONSTRAINT `fk_order_has_food_food1` FOREIGN KEY (`food_id`) REFERENCES `onlineorderfood`.`food` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) ENGINE = InnoDB DEFAULT CHARACTER SET = utf8 COLLATE = utf8_general_ci 數(shù)據(jù)字典描述 數(shù)據(jù)字典是一個(gè)數(shù)據(jù)表單數(shù)據(jù)的集合，系統(tǒng)中是用的大部分?jǐn)?shù)據(jù)都包含在了這部分里邊，因此數(shù)據(jù)字典是數(shù)據(jù)信息的最根本體現(xiàn)，下面給出部分?jǐn)?shù)據(jù)字典的描述信息： ? 員工信息表的數(shù)據(jù)字典的描述： 名字：用戶表 描述：三種用戶都可以用不同的查詢方式，獲得用戶信息，不同的權(quán)限可以查看到不同的用戶信息，如普通用戶只能看到自己的基本信息、商家用戶可以看到自己信息和訂單的信息、管理則可以看到所有的商家的信息。 定義：用戶編號(hào) +用戶姓名 +密碼 +真實(shí)姓名 +性別 +角色 +郵箱 +聯(lián)系電話 +有效性 +注 冊(cè)時(shí)間 +備注 +頭像。 位置：數(shù)據(jù)庫(kù)用戶信息表（ user） 表 21 數(shù)據(jù)庫(kù)員工信息表 序 字段名 中 文 記錄長(zhǎng)度 類 型 備 注 1 ID 用戶編號(hào) INT(10) 長(zhǎng)整型 用戶編號(hào) 2 USER_NAME 用戶姓名 VARCHAR(45) 字符型 用戶姓名 3 PASSWORD 密碼 VARCHAR(45) 字符型 密碼 4 REAL_NAME 真實(shí)姓名 VARCHAR(45) 字符型 真實(shí)姓名 5 GENDER 性別 VARCHAR(45) 字符型 性別 6 ROLE 角 色 VARCHAR(45) 字符型 角色 7 EMAIL 郵箱 VARCHAR(45) 字符型 郵箱 8 PHONE 聯(lián)系電話 VARCHAR(45) 字符型 聯(lián)系電話 9 IS_DELETE 有效性 INT(10) 長(zhǎng)整型 有效性 10 CREATED_TIME 注冊(cè)時(shí)間 TIMESMART 日期型 注冊(cè)時(shí)間 11 REMARK 備注 VARCHAR(100) 字符型 備注 12 IMAGE 頭像 VARCHAR(45) 字符類型 頭像 ? 餐品表的數(shù)據(jù)字典的描述： 名字： 餐品 表 定義：餐 品編號(hào) +餐品名稱 +價(jià)格 +圖像 +創(chuàng)建時(shí)間 +更新時(shí)間 位置：數(shù)據(jù)庫(kù)餐品信息表（ food） 表 22 數(shù)據(jù)庫(kù)部門信息表 序 字段名 中 文 記錄長(zhǎng)度 類 型 備 注 1 ID 餐品編號(hào) INT(10） 長(zhǎng)整型 餐品編號(hào) 2 FOOD_NAME 餐品名稱 VARCHAR(45) 字符型 餐品名稱 3 PRICE 價(jià)格 INT(10) 長(zhǎng)整型 價(jià)格 4 IMAGE 圖像 VARCHAR(45) 字符型 圖像 5 CREATED_TIME 創(chuàng)建時(shí)間 TIMESTAMP 日期型 創(chuàng)建時(shí)間 6 UPDATED_TIME 注冊(cè)時(shí)間 TIMESTAMP 日期型 注冊(cè)時(shí)間 ? 訂單信息表的數(shù)據(jù)字典的描述： 名字： 訂單信息表 定義：訂單編號(hào) +創(chuàng)建時(shí)間 +聯(lián)系電話 +地址 +備注 位置：數(shù)據(jù)庫(kù) 員工考勤信息表 （ check_table） 表 23 數(shù)據(jù)庫(kù)員工考勤信息表 序 字段名 中 文 記錄長(zhǎng)度 類 型 備 注 1 ID 訂單編號(hào) INT(10) 長(zhǎng)整型 訂單編號(hào) 2 CREATE_TIME 創(chuàng)建時(shí)間 TIMESTAMP 日期型 創(chuàng)建時(shí)間 3 PHONE 聯(lián)系電話 VARCHAR(45) 字 符型 聯(lián)系電話 4 ADDRESS 地址 VARCHAR(100) 字符型 地址 5 REMARK 備注 VARCHAR(100) 字符型 備注 14 以下代碼由本人獨(dú)立完成 4 區(qū)域外賣訂購(gòu)系統(tǒng)的實(shí)現(xiàn) 會(huì)員登錄模塊 會(huì)員登錄頁(yè)面設(shè)計(jì) 會(huì)員登陸界面采用 DIV+CSS 技術(shù)，實(shí)現(xiàn)頁(yè)面的裝修，拋棄之前的 table 技術(shù)，技術(shù)上面的更新，對(duì)于系統(tǒng)后期的維護(hù)提供了巨大的方便，維護(hù)期間通過(guò)直接簡(jiǎn)單的修改 css 樣式文件便可以輕松地調(diào)整系統(tǒng)登陸界面，極大地跟隨了當(dāng)下這個(gè)社會(huì)潮流的變化。 同樣，系統(tǒng)直接采用了 HTML5，而沒(méi)有使用 ， HTML5 一直被外界稱為“規(guī)范向現(xiàn)實(shí)的妥協(xié)”，系統(tǒng)內(nèi)部所有頁(yè)面也都均采用 HTML5 規(guī)范。 HTML5 具有以下優(yōu)點(diǎn)：擺脫對(duì)平臺(tái)的依賴、實(shí)時(shí)更新、離線使用、代碼更安全、跨平臺(tái)、可以充分利用 Native，系統(tǒng)設(shè)計(jì)就用到了placeholder 屬性，可以很友好地提示用戶輸入登陸信息。 系統(tǒng)登陸界面，如下圖所示： 圖 系統(tǒng)會(huì)員登陸主頁(yè)面 會(huì)員登錄隨機(jī)驗(yàn)證碼設(shè)計(jì) 為了防止暴力計(jì)算非法竊取會(huì)員信息，保障會(huì)員合法 權(quán)益，會(huì)員登陸界面會(huì)增加隨機(jī)驗(yàn)證碼設(shè)計(jì)。 圖 驗(yàn)證碼設(shè)計(jì)圖 驗(yàn)證碼前端 HTML5 代碼實(shí)現(xiàn)如下所示： 圖 驗(yàn)證碼前端 HTML 代碼圖 會(huì)員信息驗(yàn)證設(shè)計(jì) 會(huì)員登陸將會(huì)在以下兩個(gè)方面進(jìn)行驗(yàn)證，用戶名是否存在、用戶名和密碼是否匹配；外賣網(wǎng)會(huì)員在點(diǎn)擊登陸頁(yè)面的登陸按鈕時(shí)，會(huì)出發(fā)提交事件，通過(guò) Servlet 技術(shù)， Request 請(qǐng)求服務(wù)器，并將參數(shù) username、 password 傳遞給服務(wù)器，服務(wù)器通過(guò)過(guò)濾器檢測(cè)到 請(qǐng)求后，會(huì)通過(guò)控制層，系統(tǒng)中使用 @Controller 注解實(shí)現(xiàn)控制，去調(diào)配服務(wù)層的方法去執(zhí)行，服務(wù)層一般也是通過(guò) @Service 來(lái)實(shí)現(xiàn)服務(wù)，請(qǐng)看下面的 Jquery 腳本代碼展示： 16 會(huì)員登錄代碼設(shè)計(jì) 首先是 spring mvc 的控制層，這個(gè)控制層控制著 view 和 module 之間的各種交互工作，在控制器收到前臺(tái)頁(yè)面的視圖層的用戶請(qǐng)求，比方說(shuō)是 form表單的請(qǐng)求之后， dispatcherservlet 類會(huì)根據(jù)請(qǐng)求去查看控制層里面的代碼，確定調(diào)用什么樣的處理方法來(lái)相應(yīng)視圖請(qǐng)求，同時(shí)通過(guò)運(yùn) 行類方法完成相應(yīng)的業(yè)務(wù)處理，在控制層 @Controller 的 java 程序代碼中程序員們會(huì)遇到的許多的邏輯 if判斷的處理，比方說(shuō)返回，接受前臺(tái)傳遞過(guò)來(lái)的數(shù)據(jù)，以及對(duì) @service 服務(wù)層程序代碼的調(diào)用方便去完成各種各樣的業(yè)務(wù)，在登錄模塊中我們就調(diào)用了服務(wù)層的 login 方法去實(shí)現(xiàn)登錄業(yè)務(wù)。 @RequestMapping(value = /login, method = ) public ModelAndView login(@RequestParam(value = userName) String userName, @RequestParam(value = password) String password) { } 接下來(lái)展示服務(wù)層代碼 @Service，控制層在登錄的時(shí)候調(diào)用服務(wù)層的 login()方法 @Override public User login(String userName, String password) throws ParameterException, ServiceException { } 管理商家模塊 在外賣訂購(gòu)系統(tǒng)中，我們有官方平臺(tái)去管理商城會(huì)員和商城商家，在商家管理中，系統(tǒng)需要給予商家權(quán)限，讓他們能夠?qū)ψ约旱挠唵?、商家信息、商家菜單等信息進(jìn)行修改。那么，在平臺(tái)中，我們就需要有對(duì)入駐平臺(tái)的商家進(jìn)行管理，最主要的就是增刪功能、添加在平臺(tái) 的商家需要收取一定的租金，這就是平臺(tái)的盈利模式，