Appearance
一、设计规范
1.1 数据库设计规范
- 所有数据表主键必须以“ID”命名，数据类型为nvarchar(50)
- 数据表命名需要以以下规则命名：①结构数据表以 S_开头。②扩展业务数据表以 E_开头。③自定义表单数据表以 T_开头。④数据快照数据表以 R_开头。
- 禁止修改、删除表及字段。（项目组可自行增加结构表字段）。
- 自定义扩展表中，凡是与结构表存在外键关系的数据表，外键必须设置为级联删除。以避免核心API调用时发生数据库端错误。
- 所有需要开发的表单都需要单独建立自己的表单表。
- 所有字符串型字段类型全部设为nvarchar或ntext。
- 表单表所有字段除主键外都允许空。
- 项目管理中扩展表或表单表如果跟项目有关，必须固定字段：ProjectInfoID（所属项目ID）。
- 所有表单表都要有以下字段： ID（主键） CreateUserName（创建/编制人） CreateUserID（创建/编制人ID） CreateTime（创建日期） ModifyUserName(修改人) ModifyUserID(修改人ID) ModifyTime(修改日期) FlowPhase（流程状态） OrgID(所属部门ID) CompanyID（所属公司ID）
1.2 项目需求及设计规范
- 需求报告中，需明确描述包含ER图和DFD图。
- 需求报告中，需明确描述客户的主体业务流程和功能模块分布图。
- 除特别复杂的表单外（评审时确认为开发），其它表单均需要使用表单自定义进行配置开发。
- EPM产品化实施项目请按产品化实施规范执行。
二、配置规范
2.1 表单定义规范
2.1.1 表单配置
- 表单定义编号以英文命名
- 表单上有关联的枚举需要支持联动,例如:国家,省份,城市需要做成联动；
- 在同一表单中，需要保证表单边框的完整性；
- 所有表单中，保存\取消\删除…等居左需要保持一致；
- 所有表单字段名对齐可以是左对齐、右对齐、居中，但是必须保持整个系统中是一致的对齐方式；
- 表单中如果有备注信息 需要展现,则备注的可以通过加粗或用红色字体等来强调突出，但是需要全系统统一；
- 表单定义的脚本中，不能出现向后台请求修改数据的Ajax请求，所有数据修订操作的应在Save方法的事务内完成。应该尽量避免在同一个操作中发起多次Ajax请求。
- 表单上涉及到”申请人/申请部门/申请日期“，一律命名为”ApplyUser/ApplyDept/ApplyDate“
- 查询数据的SQL需要加查询条件，对于数据多的表，不能把整个表的数据全部取出；
2.1.2 控件配置
- 控件标题中不能出现非中文和英文以外的字符；
- 控件编号不能用自动生成的拼音首字母，应当用英文单词或拼音英文的缩写，要求单词首字母大写，其余小写
- 日期控件，在表单中显示时，需要将日期显示全；
- 日期的控件编号设置成Date结尾，字段类型要设置成日期型
- 所有控件和字段名称需要（上下左右）对齐；
- 子表的列根据字段内容合理设置列宽，布局中需要整行显示
- 弹窗选择框要设置成只能选择不能输入，详情里面允许输入要改成”否“
- 涉及到枚举的必须加在枚举维护里面，不能直接在表单里面自定义
2.1.3 字段设置
- 字段名称需要换行显示时，下一行至少需要显示两个字；
- 与系统用户有关的的控件编号以User结尾，与系统部门相关的控件编号以Dept结尾，控件编号不能过长;
- 金额字段需要带上单位，控件编号需要以Money结尾，字段类型要设置成浮点型，详情里要加浮点型验证;
- 涉及到客户名称、项目名称、合同名称之类的字段长度尽量设置成合理大小;
2.2 流程定义规范
2.2.1 基本信息
- 流程定义的“任务名模板”里面默认的“业务字段：{ID}”把ID换为其他的字段，否则任务里面会全是ID；
- 流程表单必须根据对应环节设置签字框
- 除特殊情况外，流程定义必须与表单定义编号相同。
- 申请人、审批人基本信息里需要勾选“可暂存”
- 若无特殊要求，字段控制中需设置只读，限制审批环节的编辑功能
- 再送流程结束环节的时候，不需要设置选人
2.2.2 路由和环节信息
- 路由名称和环节名称需要保持一致
- 流程图布局整齐，无多余环节和不需要的路由。
- 工作流定义默认需要横着画，至少要有一个开始和结束环节。
- 所有环节都要配置所属阶段名。
- 流程签字框的控件编号以Sign结尾，控件名称以“签字”结尾
- 每个环节都要勾选“保存表单”“允许驳回首环节”“允许撤销”
- 除非有特殊要求，否则要勾选禁止自动通过
- 要在字段控制中勾选签字
- 要勾选发起人删除
- 权限过滤中满足组织、角色、用户权限的人员才能执行相应操作，如果不满足即使收到了任务，也没有提交权限。
- 权限过滤中的表达、sql、变量权限，只有满足该表达式才会进去对应的分支路由。例如：{Field1}>500.0或者flag='1'
2.3 列表定义规范
- 除特殊情况外，列表定义必须与表单定义编号相同。
- 选项选择：分页、汇总行、表头列筛选；除非有特殊功能否则不要勾多选
- 列表上的所有按钮都需要配备合适图标；
- 增加\编辑\删除…等居左，显示快捷查询\详细查询居右；
- 所有记录中该字段的内容字数差不超过5个汉字的，居中对齐显 示；
- 所有记录中该字段的内容字数差超过5个汉字的，则居左对齐显示(对于内容是固定的列,如:部门名称,姓名,需要居中显示)；
- 列表中的字段是图片、按钮、选择、日期，都居中对齐显示；
- 带小数的数字、金额全部居右对齐显示，如是金额列表头上必须要有单位（如元，万元），如有小数则小数位数必须统一。
- 如该列表有流程，则必须在第一列显示流程状态，并且流程跟踪必须在流程状态字段的链接点后查看流程跟踪界面。
- 一般情况下，列表的主要字段(表单编号或查看列)需要有链接，链接点开后查看或编辑表单。
- 所有列必须指定列宽，不允许出现等宽的列。并且根据该列的数据字段长度指定相对适合的列宽。
- 表单流程列表，需要有创建人和创建时间列。
- 非流程表：增加、编辑、删除、导出Excel
- 流程表：查看流程表单、启动流程、导出Excel
2.4 Word 导出定义规范
- 除了带有特殊逻辑的Word导出可以通过二次开发的方式来实现，其它情况下所有Word导出都需要通过配置化的方式来实现。
- 富文本框导出PDF需要在word模板—域—域属性—域名的最前面加上“Html:”，避免导出的PDF里面有多余的空格和换行。例如：将域名“PresentationContent”修改为域名“Html:PresentationContent”
2.5 枚举配置要求
- 定义系统枚举时，枚举编号必须加上前缀“数据库链接串名称.”；
- 除特殊情况外，枚举配置定义的枚举Key和枚举Value必须保持一致；
2.6 Web.config配置要求
- 是否分布式事务，在系统上线到正式服务器上时，需要将此配置为：True；
- 是否启用缓存，在系统上线到正式服务器上时，需要将此配置为：True；
- 平台不能输入的字符，在系统上线到正式服务器上时，需要将此配置为： '|%27；
三、配置管理规范
- 主体开发阶段后，上线评审需要确认配置库信息完整，并确认发版时间戳，客户现场进行初始化安装；
- 上线反馈调整阶段，配置以现场数据为准，每次现场修订需要把配置库备份回来，在公司还原之前需要开发经理认可确认；
- 上线反馈调整阶段，开发人员需要根据时间戳记录整理出差异更新sql语句，提交客户现场进行sql差异更新；
- 客户现场除初始化安装外，不允许备份库整库还原；
- 纳入管理范围的内容包括更新的内容有：模块、元数据、表单、列表、流程、透视表、报表、菜单、选择器、Word导出、枚举；不需要统一更新的内容有：授权对象、系统角色、组织角色；
四、编码规范
4.1 源代码分层结构规范
- 产品发布的源代码结构，未经设总确认，禁止随意改动。 项目文件夹结构如下
平台源代码统一放在BaseFrame目录下，除了Resource开放给项目生产外，其它Formula、MvcAdapter和Config.Logic三个工程不提供源码：
所有web程序需放在一个webApp目录下（包括产品的）
业务逻辑层需要放在 BusinessModule目录下，BusinessModule目录中分为BaseLogic与Logic
BaseLogic存放平台级的业务层代码，除了Base.Logic和WebOffice.Logic源码开放给项目生产外，FileStore.Logic和Workflow.Logic两个工程不提供源码：
Logic存放项目上的业务层代码
- 自行开发的业务模块，按2层分布， xxx.Logic 为业务逻辑层 MVC4 工程为WEB应用。其中MVC的MODEL需要包含在业务逻辑层；
- 子业务模块的功能在对应Area下开发。禁止将所有的功能模块全部放在根目录的Controller和View下；
4.2 平台扩展规范
- 平台级代码类库禁止直接修订源代码，如经技术质量部确认需要扩展平台的，须使用分部类方式扩展平台。
- 如遇项目特殊需求，平台无法满足，产品又没有规划的情况，确实需要修订平台内容，请至技术质量部/PMO处备案后由研发部指导修订。
- 前端脚本扩展，自定义创建JS文件，并放置在项目的Script文件夹下。
4.3 编码规范
- 源代码中禁止出现硬编码。
- 源代码中禁止随意定义静态变量。
- 源代码需要整洁，清晰。
- 实现业务逻辑应写在业务逻辑层。如自定义开发流程的表单提交操作，应该在业务逻辑层进行实现。
- 方法或类名需要以英文定义且首字母大写。
- 数据级权限需要使用平台配置功能实现（如特殊内容需要编码，请在开发评审前列明）。
- 关键性或特殊性逻辑代码，需要注释（关键方法或特殊逻辑方法需要三杠注释）。
- 不能留有与本页面逻辑不相关的废代码。
- Logic层不允许相互引用，例如 Market.Logic不能引用Project.Logic，以避免出现循环引用，跨领域的引用均在MVCApplication中进行。
- MVCApplication或WebApplication 禁止相互引用。
- 创建FO实例或Service实例对象时，需使用使用平台提供方法，禁止直接实例化。
- 对于项目管理经营的对象扩展需要使用分部类方式扩展，partial xxx.cs(EF分布类) 。
- 自行编写的业务属性必须加上 NotMapped 标签。
- 禁止使用静态方案扩展EF对象。静态方法统一写入FO层。
- VC工程禁止使用ASPX页面进行二次开发。
- 逻辑校验需要在服务端实现。
- 前端脚本中，如果需要使用固定常量时，需要使用web.config中的ToWeb节定义来定义脚本常量。
五、其他规范
5.1 评审技术要求规范
- 公司级战略项目和重点项目主体开发阶段必须经过公司技术质量部的测试和评审，回归后方可部署到客户环境；如项目生产上有冲突，需经过生产副总同意，并邮件公司（PMO/技术质量部）备案。
- 安装上线后确认产值时，需要如下证明：
5.2 QA审查内容
公司每个季度针对各部门主体上线项目开展技术审查工作（抽查），抽查内容包括：
- 【代码】SVN上的代码结构需符合上文要求规范。
- 【代码】上线及反馈阶段的项目，SVN上需有2周内的签入记录。
- 【代码】SVN获取代码后必须编译成功。
- 【数据库】各生产部门数据库服务器上数据库完整。
- 【部署环境】客户正式服务器上不能放置webApp以外的源码。
- 【部署环境】客户正式服务器上不能安装开发调试环境。
- 【部署环境】客户正式服务器IIS配置上需遵循公司安全规范。
- 【部署环境】web.config的配置需遵循上文规范。