网上花店销售管理系统

　　1 绪论

　　1.1背景

　　我国鲜花业传统落后、独立分散的营销方式已经不能满足人们对鲜花预订的需求，因此建立一个电子商务下的鲜花在线预订系统是十分必要的，这样可以减少流通环节、降低交易成本、突破时空限制、节省订购、支付和配送时间。

　　网上的商品销售系统应以也浏览用户提供商品信息为核心，以降低成本提高利润为目标的信息管理系统，对于传统的客户上门订购、检验，签署付款等流程是个新生事物，融入了客户端/服务器管理模式、企业资源计划等先进的管理思想，为加强财务管理、建立高效率供销链、减少库存、提高工作效率、降低运营成本、提高服务质量等方面提供强有力的工具，以提高企业的市场竞争力，创造最大效益。对于用户而言，为了节省用户的宝贵时间，用户可以通过商品公告栏了解当前鲜花的最新动态，省去了无谓的查找时间和精力。在经济效益方面，企业无需在中低端销售环节进行巨大的运作投入，如人员、仓储、货运，而将主要精力投放在高端产品的引进和批发销售等环节，避免了资源分散及由此带来的管理风险，从而集中优势资源保持企业的核心竞争力，同时还缩短了生产商与消费者之间的距离，有利于商品的快速流通，和降低整体分销成本。

　　1.2 系统开发可行性研究

　　在决定开发爱尚生活鲜花预定系统应用项目之前，首先要做好系统开发的可行性分析。可行性分析的任务是确定项目开发是否必要和可行。建设网站的必要性取决于需求的迫切性和实现的可行性。从以下几个方面认真进行研究，从而为确定网站开发项目的决策提供科学依据。

　　1).经济可行性：对组织的经济状况和投资能力进行分析，一方面是支出的费用，其中包括设备购置费、软件开发费、管理和维护费用、人员工资和培训费等;另一方面是取得的收益，其中有一部分可以用钱来衡量，如开发本网站，为商家销售商品提供更多的机会。收益的另一部分难以用钱表示，如加强商品信息管理。

　　2).技术上可行性：现技术上的可行性分析所考虑采用的硬件和软件技术能满足用户提出的要求(如计算机的容量、速度等)。此外，因本网站难度不大，所以在技术上已达到开发该网站的能力。

　　3).营运上的可行性：指系统对组织结构的影响，现有人员和结构、设备、环境等系统的适应性以及进行人员培训补充计划的可行性。

　　4).管理上的可行性：重要是管理人员对开发网站的态度和管理方面的基础工作。重要领导不支持的项目肯定不可行。管理基础工作好坏重要表现在管理制度和方法是否科学，规章制度是否齐全以及原始数据是否正确等方面。

　　2需求分析

　　2.1网上花店销售管理系统的功能要求

　　通过总结，本系统的主要实现以下功能：

　　(1)商品浏览：使用户进入页面不用登录页可以浏览鲜花及信息。

　　(2)商品搜索：用户可以通过商品类别检索、商品价格检索或者模糊检索来查找自己需要的产品，或者输入节日，送礼对象等来搜索产品，系统会提供相应的产品以供用户选择。

　　(3)配送范围：主要说明哪些地方是可以配送鲜花。

　　(4)购物车：用户可以查看和修改自己的购物车信息，提交确定需要购买的产品。

　　(5)订单管理：在订单管理中可以批量查询所有订单，还可以通过订单号查询订单，这样可以及时送货。

　　(6)商品管理：可以通过主/分分类别对鲜花进行修改或者删除，也可以批量查询商品，及时添加商品和修改商品，以提高鲜花销售在市场上的竞争力。

　　(7)商品类别管理：商品类型信息的增加删除修改。

　　(8)系统信息管理：管理退出系统，修改密码。

　　图2.1 系统总体层次结构图

　　2.2系统的数据需求

　　网上花店销售管理系统的数据需求包括如下几点：

　　(1)数据录入和处理的准确性和实时性

　　数据的输入是否准确是数据处理的前提，错误的输入会导致系统输出的不正确和不可用，从而使系统的工作失去意义。数据的输入来源是手工输入。手工输入要通过系统界面上的安排系统具有容错性，并且操作人员应当具备一般的计算机操作水平。

　　(2).数据的一致性与完整性

　　由于系统的数据是共享的，对于输入的数据，要为其定义完整性规则，如果不能符合完整性约束，系统应该拒绝该数据。

　　(3).数据的共享与独立性

　　整个爱尚生活鲜花预定系统的数据是共享的。然而，从系统开发的角度上看，共享会给设计和调试带来困难。因此，应该提供灵活的配置，使各个分系统能够独立运行，而通过人工干预的手段进行系统数据的交换。这样，也能提供系统的强壮性。

　　2.3运行环境

　　表2. 运行环境

　　2.4建立网上花店销售管理系统的约束

　　(1).B/S结构总体设计方案对它的约束

　　爱尚生活鲜花预定系统做为B/S结构的一个应用系统，不可避免的要受到B/S结构的约束。在其实施的各个阶段都要服从它的一些规划，包括功能设计、系统配置和计划。同时，由于信息的共享，爱尚生活鲜花预定系统还受到其它系统的信息约束。

　　(2)技术发展规律的约束

　　计算机技术和产品的发展日新月异，将会给信息处理带来更多的手段，同时也会带来更加丰富的信息表达形式。例如图象和语音技术的进步，多媒体技术的发展，这些都要求系统在设计时考虑技术变化的可能性，为可能的变化预留一定的系统处理能力。

　　2.5ASP.NET部署三层架构

　　分层的应用程序构造方法有以下一些优点：有利于代码复用;方便程序改动;提高代码的健壮性;有利于分工。在系统设计中，用到三层架构，即：数据连接层，业务逻辑层和页面表现层。

　　2.5.1数据连接层

　　根据调用者提供的SQL语句、存储过程名称及参数等数据库对象信息返回一定格式的应用程序对象。数据组件需要数量相对较少，但使用面很广。

　　在数据库连接层中，主要定义了如方法和全局变量：

　　表2. 数据库连接主要方法

　　2.5.2业务逻辑层

　　业务层主要任务为构造业务对象和调用数据组件从数据库获取数据，这是实现起来最复杂的一个层面，需要熟悉数据库结构，并根据用户层需要设计业务对象及数据库对象。

　　在系统中，为每个模块设定了相应的类，主要包含的类文件：

　　表2. 系统业务逻辑层类文件

　　2.5.3页面表现层

　　在页面层不需要再和数据库打交道，只需调用相应的业务组件即可，这样就算界面有大的改动也可从容自如。

　　3数据库设计

　　3.1数据库总体设计

　　系统采用Microsoft SQL Server 2005作为系统的后台数据库开发环境。根据系统的功能来设计，系统数据库表包括商品表，商品类别表，管理员表，订单表和订单明细表。

　　表3. 系统数据库表

　　3.2数据库表设计

　　3.2.1商品

　　商品表，用来存储鲜花的基本信息。

　　表3. 商品表

　　注：文件路径数据均采用相对地址存储。

　　3.2.2商品类别

　　商品类别存放了鲜花类别信息。

　　是系统运行的模块数据示例：

　　图3. 商品类别数据示例图

　　表3. 商品类别表

　　3.2.3管理员

　　管理员主要是进行后台管理操作的。

　　表3.4 管理员表

　　3.2.4订单

　　表3.5 订单表

　　3.2.5订单明细

　　表3. 订单明细表

　　4标准与规范

　　4.1对象命名约定

　　表4. 对象命名约定

　　特别地，所有日期控件用

　　在相应的页面中引入JS文件：

　　4.2结构化编码约定

　　///

　　///定单信息列表

　　///

　　///

　　///

　　public List GetOrderList()

　　{

　　dataAccess = new BaseAccess();

　　List listOrder = new List();

　　SqlConnection conn;

　　Orderinfo objOrder = null;

　　string sql = "Select * from 订单 ";

　　SqlDataReader dr = dataAccess.ExecuteDataReader(sql, out conn);

　　while (dr.Read())

　　{

　　objOrder = new Orderinfo();

　　objOrder.No = Int32.Parse(dr["订单编号"].ToString());

　　objOrder.UserNo = Int32.Parse(dr["用户编号"].ToString());

　　objOrder.Money = dr["销售金额"].ToString();

　　objOrder.Address = dr["收货地址"].ToString();

　　objOrder.State = dr["订单状态"].ToString();

　　objOrder.OrderTime = DateTime.Parse(dr["订单时间"].ToString());

　　objOrder.ConsigneeName = dr["收货人姓名"].ToString();

　　objOrder.Tel = dr["收货人电话"].ToString();

　　UserManage objUserManage = new UserManage();

　　Userinfo objUser = objUserManage.GetUserInfoByNo(objOrder.UserNo);

　　objOrder.Shopper = objUser;

　　listOrder.Add(objOrder);

　　}

　　dr.Close();

　　conn.Close();

　　return listOrder;

　　}

　　4.3数据源约定

　　数据源的组件一律采用控件。

　　4.4数据库访问

　　数据库访问都是通过调用DataAccess类来实现，这样不仅可以减少后台代码的冗余，而且能增强代码的可维护性。

　　4.5其他访问约定

　　DataGrid的数据绑定，DropDownList的初始化都是通过调用Common类来实现，下拉数据的下拉项都是通过字典表中的数据来绑定，或者选择数据库中的其他数据来绑定，单选只包含了两个选项，在数据库中采用bit类型的数据，对于这种情况不采用从数据库提取数据初始化选项。