一、技术部分

后端基于thinkphp5.1框架

简介

ThinkPHP是一个开源的，快速、简单的面向对象的轻量级PHP开发框架，是为了敏捷WEB应用开发和简化企业应用开发而诞生的。ThinkPHP从诞生以来一直秉承简洁实用的设计原则，在保持出色的性能和至简的代码的同时，也注重易用性。遵循Apache2开源许可协议发布，开发文档健全。

命名规范

ThinkPHP5遵循PSR-2命名规范和PSR-4自动加载规范，并且注意如下规范：

目录和文件

· 目录使用小写+下划线；

· 类库、函数文件统一以.php为后缀；

· 类的文件名均以命名空间定义，并且命名空间的路径和类库文件所在路径一致；

· 类文件采用驼峰法命名（首字母大写），其它文件采用小写+下划线命名；

· 类名和类文件名保持一致，统一采用驼峰法命名（首字母大写）；

函数和类、属性命名

· 类的命名采用驼峰法（首字母大写），例如 User、UserType，默认不需要添加后缀，例如UserController应该直接命名为User；

· 函数的命名使用小写字母和下划线（小写字母开头）的方式，例如 get_client_ip；

· 方法的命名使用驼峰法（首字母小写），例如 getUserName；

· 属性的命名使用驼峰法（首字母小写），例如 tableName、instance；

· 以双下划线“__”打头的函数或方法作为魔术方法，例如 __call 和 __autoload；

常量和配置

· 常量以大写字母和下划线命名，例如 APP_PATH和 THINK_PATH；

· 配置参数以小写字母和下划线命名，例如 url_route_on 和url_convert；

数据表和字段

· 数据表和字段采用小写加下划线方式命名，并注意字段名不要以下划线开头，例如 think_user 表和 user_name字段，不建议使用驼峰和中文作为数据表字段命名。

应用类库命名空间规范

应用类库的根命名空间统一为app（不建议更改，可以设置app_namespace配置参数更改，V5.0.8版本开始使用APP_NAMESPACE常量定义）；
例如：app\index\controller\Index和app\index\model\User。

目录结构

架构总览

ThinkPHP5.0应用基于MVC（模型-视图-控制器）的方式来组织。

MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型（M）、视图（V）、控制器（C），它们各自处理自己的任务。

5.0的URL访问受路由决定，如果关闭路由或者没有匹配路由的情况下，则是基于：

http://serverName/index.php（或者其它应用入口文件）/模块/控制器/操作/参数/值…

下面的一些概念有必要做下了解，可能在后面的内容中经常会被提及。

入口文件

用户请求的PHP文件，负责处理一个请求（注意，不一定是URL请求）的生命周期，最常见的入口文件就是index.php，有时候也会为了某些特殊的需求而增加新的入口文件，例如给后台模块单独设置的一个入口文件admin.php或者一个控制器程序入口think都属于入口文件。

应用

应用在ThinkPHP中是一个管理系统架构及生命周期的对象，由系统的 \think\App类完成，应用通常在入口文件中被调用和执行，具有相同的应用目录（APP_PATH）的应用我们认为是同一个应用，但一个应用可能存在多个入口文件。

应用具有自己独立的配置文件、公共（函数）文件。

模块

一个典型的应用是由多个模块组成的，这些模块通常都是应用目录下面的一个子目录，每个模块都有自己独立的配置文件、公共文件和类库文件。

5.0支持单一模块架构设计，如果你的应用下面只有一个模块，那么这个模块的子目录可以省略，并且在应用配置文件中修改：

'app_multi_module' => false, 

控制器

每个模块拥有独立的MVC类库及配置文件，一个模块下面有多个控制器负责响应请求，而每个控制器其实就是一个独立的控制器类。

控制器主要负责请求的接收，并调用相关的模型处理，并最终通过视图输出。严格来说，控制器不应该过多的介入业务逻辑处理。

事实上，5.0中控制器是可以被跳过的，通过路由我们可以直接把请求调度到某个模型或者其他的类进行处理。

5.0的控制器类比较灵活，可以无需继承任何基础类库。

一个典型的Index控制器类如下：

namespace app\index\controller;  class Index  {     public function index()     {         return 'hello,thinkphp!';     } } 

操作

一个控制器包含多个操作（方法），操作方法是一个URL访问的最小单元。

下面是一个典型的Index控制器的操作方法定义，包含了两个操作方法：

namespace app\index\controller;  class Index  {     public function index()     {         return 'index';     }          public function hello($name)     {         return 'Hello,'.$name;     } } 

操作方法可以不使用任何参数，如果定义了一个非可选参数，则该参数必须通过用户请求传入，如果是URL请求，则通常是$_GET或者$_POST方式传入。

模型

模型类通常完成实际的业务逻辑和数据封装，并返回和格式无关的数据。

模型类并不一定要访问数据库，而且在5.0的架构设计中，只有进行实际的数据库查询操作的时候，才会进行数据库的连接，是真正的惰性连接。
ThinkPHP的模型层支持多层设计，你可以对模型层进行更细化的设计和分工，例如把模型层分为逻辑层/服务层/事件层等等。

视图

控制器调用模型类后返回的数据通过视图组装成不同格式的输出。视图根据不同的需求，来决定调用模板引擎进行内容解析后输出还是直接输出。

视图通常会有一系列的模板文件对应不同的控制器和操作方法，并且支持动态设置模板目录。

驱动

系统很多的组件都采用驱动式设计，从而可以更灵活的扩展，驱动类的位置默认是放入核心类库目录下面，也可以重新定义驱动类库的命名空间而改变驱动的文件位置。

行为

行为（Behavior）是在预先定义好的一个应用位置执行的一些操作。类似于AOP编程中的“切面”的概念，给某一个切面绑定相关行为就成了一种类AOP编程的思想。所以，行为通常是和某个位置相关，行为的执行时间依赖于绑定到了哪个位置上。

要执行行为，首先要在应用程序中进行行为侦听，例如：

// 在app_init位置侦听行为 \think\Hook::listen('app_init'); 

然后对某个位置进行行为绑定：

// 绑定行为到app_init位置 \think\Hook::add('app_init','\app\index\behavior\Test'); 

一个位置上如果绑定了多个行为的，按照绑定的顺序依次执行，除非遇到中断。

前端基于React框架

l 关于服务器配置建议

二、技术运维服务内容

一年的技术维护服务内容包括：在乙方服务责任范围内保证网站的正常运行使用。但不包括因非本合同内乙方提供的服务器、网络等因素引起的访问故障、因非乙方人员错误操作所造成的运行故障或网站结构的改变、设计风格的改变和功能模块的增加、网站内容维护。详情如下：

1、安全漏洞修补
对由甲方或甲方委托的第三方安全技术代理公司查出的安全漏洞进行代码修补。

2、灾难修复
若正式上线的服务器，即网站服务环境发生崩溃，配合甲方公司进行系统的恢复工作，恢复到系统交接时的状态，即正式上线节点时状态，数据需由甲方公司提供数据库备份文件和用户文件（上传文件）备份。

3、技术保障
3.1对于使用方面的问题，提供电话维护。
3.2维护项目包括由于系统设计问题而出现的系统故障、系统运行错误。非软件系统设计问题，如：硬件损坏、使用者操作不当、使用者恶意行为造成的系统问题故障不含在维护范围内。

二、 服务方式

出现问题或故障后，甲方通过邮件/电话等形式向乙方提出要求，乙方根据甲方要求的以下一种或几种服务方式为甲方提供服务：

1、电话应答服务

乙方为甲方指定经验丰富的专职人员，与甲方相关人员对接。负责解答、帮助处理在使用过程中所遇到的故障或困难。

2、远程桌面协作服务

甲方须向乙方开放服务器的远程桌面服务，以便于乙方对甲方的网站系统进行正常的维护和故障排除。

乙方承诺未经甲方书面许可，不将甲方服务器任何信息向任意第三方传播，否则应当赔偿由此给甲方造成的损失。此义务不因本合同的终止而终止。

3、上门服务

如确有必要，经由甲乙双方协商，指定专业人员，上门服务。

三、 服务响应时间

1.工作日响应时间为：5*8小时

2.出现上述问题或其他异常问题，甲方通过邮件的形式向乙方提出要求后，乙方将在24小时内（以甲方发出的邮件记录的时间为起点）处理完成。

3.若有突发或紧急情况不在工作时间内，可与项目经理协商极速解决。

四、 后期托管维护内容清单和报价

设计人/天：1500（元）

技术人/天：2500（元）

备注说明：

* 价格为服务人/天单价，最终以实际作业数量核算。

* 不包含正版图片等采购费用