U8二次开发规范.doc

U8二次开发规范1. 背景目前U8产品越来越庞大，提供的应用与服务也越来越多样化。公司整体的发展战略要求U8要成为一个能支持规模化交付的产品。为了达到这样的目标，仅仅通过我们的水平产品是无法满足客户的行业化、个性化的要求的。所以二次开发就成为一个能满足可以要求的填充剂，填补水平产品与客户的需求中的差异的空隙。2. 二次开发定义及范畴二次开发是与一次开发是相对应的，所以凡是由U8产品开发部提供的U8产品、套件以外的都应属于二次开发的产品。从这个定义出发以下行为属于开发开发范畴。n 分公司、大区的基于U8的开发行为。n 第三方合作伙伴的基于U8的开发行为。n 行业开发本部基于U8产品的开发行为。3. U8ERP二次开发模式分析目前我们的二次开发处于缺乏管理状态。由于U8软件缺乏足够的开放性，导致二次开发人员能利用的手段和方法非常有限。同时由于U8每年都需要年结，造成二次开发的数据需要手工结转。甚至有些是利用原代码进行的修改，这种方式会因为版本升级而造成功能失效。以下列出了主要的开发模式。1. 独立开发模式，独立于产品l 模式描述：在开发过程中基本不利用U8产品的构件（只利用登录构件），开发成果形成单独的可执行文件及动态库，模块不需要与U8门户程序集成，二次开发模块的权限设置、功能升级、部署均独立于产品。l 优点：对产品的影响小，产品可升级性强，不受产品功能制约。模块功能灵活度大，能够实现很复杂的功能。l 缺点：二次开发的模块产品风格与U8 产品风格差距较大，产品中一些很完善的功能（权限、打印、格式设置、输出等）不能被二次开发利用，打印、输出等基础功能需要重新开发，开发效率低。l 注意问题：如果使用了U8登录构件，在产品升级后，应测试登录构件是否向下兼容，如果不兼容要根据新版登录构件的使用文档对二次开发程序的登录部分作修改。l 禁止行为：为最大限度的保证产品的可升级性，禁止直接修改产品的系统数据表、视图、存储过程等数据库对象。l 适用需求：与产品关联度小，二次开发的功能与产品相对独立，属单独的功能需求，不影响产品的业务流程，但允许由产品中取数。例如：在U8ERP产品的基础上增加提成管理系统。2. 通过产品插件接口开发模式l 模式描述：此模式的开发是利用产品开放的插件接口对原产品模块做功能扩展。开发成果形成单独的动态链接库，模块功能不能单独使用，一般由产品模块通过插件接口依据插件注册信息自动调用。二次开发模块的权限设置、功能升级、部署均独立于产品。l 优点：利用插件方式开发，对产品影响小，产品可升级性强。插件机制可以规范二次开发模块的开发方式，插件产品重用性强，功能配置灵活。l 缺点：受产品插件接口开放程度的限制，目前只有库存模块提供了二次开发插件接口，其他模块还未提供，而库存模块也只提供了单据保存、审核、明细行双击等部分事件的插件接口，面对用户多种多样的二次开发需求，产品的插件接口开放程度还很不够。l 注意问题：插件开发应完全符合U8产品提供的插件二次开发规范，尽量采用与产品一致的开发语言(VB6.0)做插件，保证插件数据库操作与产品的数据库操作在同一事务中。l 禁止行为：l 适用需求：客户需求与产品模块结合紧密，需要基于某一产品模块做功能扩展，尽量采用插件方式。3. 利用产品提供的工具、服务的开发模式l 模式描述：利用产品提供的二次开发工具、二次开发服务实现客户的个性化需求的开发模式。l 优点：基本不用或只做少量的编码工作、开发效率高、与原产品风格一致、集成度高、易部署。l 缺点：产品提供的开发工具能够解决的问题有限，特别是针对二次开发常涉及的供应链、财务等模块，目前只提供了自定义报表的二次开发工具。l 注意问题：l 禁止行为：l 适用需求：能够利用产品提供的二次开发工具开发的需求尽量采用二次开发工具实现。例如：为客户定制开发的业务报表，一般的业务报表利用产品的自定义报表功能都可以实现。4. 申请产品源码做修改、替换原产品模块或新增模块节点的开发模式l 模式描述：向集团申请源码直接修改产品功能模块的方式。l 优点：基于原产品模块的代码进行二次开发可以实现很复杂的功能，开发灵活性、与产品集成度高。l 缺点：如果需要以这种模式进行二次开发，必须首先向集团伙伴开发部申请开放部分源码，由伙伴开发部提供二次开发环境，分公司程序员不得将源码带回分公司。如果采用新增模块的方式，产品可以做补丁升级；如果采用替换原产品模块的方式导致产品不能进行升级，否则产品升级后会覆盖二次开发的模块，一定要升级需要二次开发人员对升级的安全性做测试，确认产品升级后不会影响二次开发模块的功能。l 注意问题：应慎重选择此种开发模式，这种模式最大的问题就是严重影响产品的数据安全性、影响产品的正常升级。l 禁止行为：没有二次开发程序员的指导，不能由用户自行进行产品补丁升级工作。l 适用需求：适用于不能利用插件接口、外挂模块、二次开发工具的开发的需求，且此类需求的实现必须基于产品模块做修改。5. 行业插件的开发模式l 模式描述：行业本部针对某个行业的行业特点对产品局部功能做行业化改造或开发新模块的开发模式，最终形成行业插件产品。l 优点：开发规范遵循U8产品的开发规范，与产品开发过程一致。行业插件产品经过严格、专业的测试，保证开发质量。l 缺点：l 注意问题：行业插件产品要注明适用的产品版本，提供详尽的联机帮助、使用说明、升级方法。同时要考虑能够随产品的升级而升级。l 禁止行为：禁止随意占用产品的模块编号做单据模板、报表模板的预置工作，行业本部增加模块前需向产品管理部申请全套模块代码及相关标识。l 适用需求：行业插件产品的开发。4. U8ERP二次开发行为规范针对目前的开发现状现我们分几个方面制定开发行为规范，以此规范开发人员的行为，告诉二次开发人员哪些行为是安全的，哪些行为是危险的。4.1. 独立模块开发规范。利用VB或其他开发工具开发独立的模块是目前一般的开发行为，这种开发方式对U8的依赖最低，藕合度小，受到的升级的影响也最小。在目前U8开发性比较低的情况下这是一种合理的选择。但是这种方式无法做到与系统的无缝结合。在UI的风格上也有可能造成较大的差异。开发分以下阶段进行。l 需求调研阶段：调研规范：二次开发调研不同于产品功能调研，客户提出的需求有可能代表一类行业的应用方式，但也有可能为该客户独有的需求。要求二次开发人员必须仔细分析客户提出需求的原因，首先确定是否可以通过软件以变通的方式实现用户的需求，确认没有其他解决方案后才可定义为二次开发需求。需求规范：对于典型行业的二次开发的需求，且符合集团行业开发部做行业项目支持的条件，需要遵循行业开发部提供的二次开发需求模板编写二次开发需求文档。需求文档要严格按照模板内容逐项编写，特别要注意业务算法、数据精度、效率要求等设计相关的内容一定要作深入调研。对于分公司负责开发的项目，也可以参照行业开发部提供的二次开发需求模版进行需求编写，作为下一步设计、研发的指导性文档。二次开发需求完成后，首先要经过用户确认，然后提交项目组召集相关需求、设计、研发人员进行需求评审，需求确认后即可进行设计、研发工作。l 设计阶段：设计原则：1) 需求设计一致性：二次开发模块设计必须满足软件需求说明书的所有要求，包括所有功能要求、性能要求和其它要求。软件需求说明的变化与软件设计说明书的变化必须保持一致。变化不能随意进行，应置于严格的配置管理之下，对于软件需求确认后的变更要严格控制，避免二次开发周期过长。2) 数据结构独立性：对于二次开发的模块禁止修改产品系统表数据结构及相关视图、存储过程、触发器等数据对象，最大限度的保证产品的可升级性。二次开发新建数据对象的命名规则应遵从二次开发数据对象命名规范。3) 数据一致性、合法性：设计过程中要考虑二次开发模块与相关产品模块数据的一致性。首先要保证产品的数据安全，尽量避免直接新增或修改系统数据表的记录。如果确实需要维护系统数据表的记录，尽量采用产品开放的业务组件操作数据库记录，保证数据的完整性、合法性。4) 产品化原则：对于有可能产品化或插件化的二次开发需求，在设计时要考虑二次开发模块的通用性、可推广性。二次开发模块要达到易安装、易使用、易维护的设计要求。尽量使用U8产品使用的构件，需要向集团申请模板编号、模块编号，避免和产品冲突。l 编码阶段：1) 尽量采用与产品模块开发语言一致的开发语言。2) 首先VB语言编码规范遵循U8产品使用的VB编码规范,见附件。利于二次开发模块的产品化。其他开发语言编码规范也可参照VB的编码规范执行。3) 其次，作如下补充：注释规范：模块开头说明：增加“相关产品模块及本模块与产品模块的关系”、“作者单位”、“作者电子邮箱”、“适用产品版本”4) 配置管理工具可采用SourceSafe作配置管理。4.2. 第三方集成开发规范EAI二次开发可分为两种模式：一、直接利用EAI管理工具。利用EAI工具可以将U8数据以标准XML文件的形式导出U8数据库或将标准XML数据文件导入U8系统。二次开发程序员需要编写一个工具将标准XML数据文件进行适当转换写入外部系统或取出外部系统数据写成标准XML数据文件。数据流程如下：EAI工具导出数据Xml文件数据写入外部系统U8Xml文件从外部系统读出数据EAI工具写入数据外部系统EAI工具完成EAI二次开发的工作优点：这种开发模式比较简单，充分利用EAI工具提供的功能，编程简单；缺点：只能提供批量导入导出功能。二、利用EAI提供的组件，进行灵活的二次开发。包括两种方式：本地COM方式、Internet方式。1）本地COM方式：U8数据处理外部系统EAI组件调用接口二次开发出的软件二次开发的工作功能：这种方式可根据开发者的需要批量处理或者实时处理。优点：接口调用非常简单，简化了编程，开发者只需将标准数据传入接口即可。2）Internet方式：U8外部系统IIS服务器二次开发模块SOAP协议二次开发工作功能：这种方式可根据开发者的需要对数据进行实时处理，可实现远程数据导出导入。优点：接口调用简单，适用于远程调用方式。缺点：不能适于大数据量数据的导入。EAI应用开发规范：n EAI工具目前不适用于大数据量的一次性导入，否则会导致导入时间过长甚至造成不能导入的问题，在数据量较大时最好拆分成多个小文件，再做导入。n 目前EAI不支持对业务单据的删除、修改功能，要求第三方软件的业务单据导出数据后不能再在原系统中修改造成系统间业务数据不一致。在从第三方软件导出业务单据前，要保证业务单据上涉及的基础档案在U8系统内已存在，否则应连带先将关联基础档案导出，向U8系统导入相关基础档案后，再导业务单据，保证业务数据的完整性。4.3. 二次开发项目命名规范U8中使用的产品有自己的规范，产品以大写的英文字母表示如AR应收系统，该产品下的子产品用产品的字母开头后面接字母或数字AR101设置，AR10101初始设置，在门户的中的显示为树的形式，其中AR为AR101的父节点，AR101为的父节点。其他新产品的起名，或二次开发的产品的起名必须遵循上面的规则，并不能和已有的产品名称相重，下面是在U8ERP中以使用的产品名称及相应的对应的关键字。序号关键字产品名称 1AR应收系统2AP应付系统3BM预算管理4BO物料清单5CA成本管理6CM合同管理7CO网上结算8CP产能管理9CR合并报表10CSCRM系统11DA企业营运分析12EA企业应用集成13EC工程变更14EQ设备管理15EX出口管理16FA固定资产17FC车间管理18FD结算中心19FM资金管理20GF集团财务21GL总账22GR公司对账23GSGSP质量管理24HBHR基础设置25HM人事管理26HT人事合同管理27IA系统菜单28MC经理查询29MO生产订单30MP主生产计划31MQ需求规划32NB网上银行33NE网上报销34OM委外管理35PA售前分析36PM项目管理37POWEB财务38PP采购计划39PS管理驾驶舱40PU采购管理41QM质量管理42RT招聘管理43SA销售管理44SG专家财务评估45SOWEB购销存46ST库存管理47TM考勤休假管理48TR培训管理49WA工资管理50WH报账中心51WM保险福利管理对于二次开发项目需要确认项目编号，在以后定义菜单、组件名称、数据库命名时必须在相关的位置遵循此规范。规范如下：客户化开发项目的开头必须是EF，然后是项目名，如EFNF表示是二次开发南孚项目。此长度不能超过6位。插件产品的开头必须是PF,然后是插件名，如服装插件表示为PFFZ，总长度不得超过6位。标准插件产品好将占用以下编号，这些编号与标准产品一样不允许使用4.4. 二次开发菜单命名规范 二次开发项目的菜单命名开头是项目名如：EFNF。 一级产品名称长度为2位，如：EFNF01。 二级产品名称长度为2位, 如：EFNF0101。 三级产品名称长度为2位, 如：EFNF010101。 无论是独立的二次开发子产品还是在标准产品下增加二次开发菜单都要求遵循此规范。 总长度为不能超过14位。4.5. 二次开发权限命名规范4.6. 模板预置命名规范【单据、打印模板】 单据打印模板数据的CardNum字段的前缀必须是项目编号，后面的预置可以自由定义。如：EFNF001【栏目模板】 栏目预置在Meta库中，其cKey字段的前缀必须是项目编号，后面的预置可以自由定义,cProjectNO字段值不能是U870，必须使用项目号。如：EFNF001【过滤模板】过滤预置在Meta库的flt_defineMeta_Base表中，其FilterID字段的前缀必须是项目编号，后面的预置可以自由定义,ProjectNO字段值不能是U870，必须使用项目号。如：EFNF0014.7. UAP产品命名规范由于UAP开发的产品的所有部件都是通过GUID来进行控制的，所以不会出现冲突情况但相关命名还是需要遵循命名规范UAP二次开发不能使用U870项目（U870项目默认也无法看到），否则会出现升级后二次开发信息丢失的情况。【UAP项目】UAP产品在使用前都需要先定义一个项目，此项目必须遵循二次开发项目命名规范。【数据引擎】 实体名称必须以项目号和下划线作为前缀，并以ENT作为结尾。如EFNF_CGDD_ENT 业务对象名称必须以项目号和下划线作为前缀，并以BO作为结尾。如EFNF_CGDD_BO【参照】 参照的编号必须以项目编号和下划线为开头如：EFNF_Customer。5. U8ERP的开发规范5.1. 界面一致性规范U8ERP产品已经制定的严格的一致性规范，点击下面的连接可以看到规范。请直接查看人机工程部的规范要求。5.2. 代码规范5.2.1. VB程序组件命名规范VB组件命名需要在组件前面增加项目编号，如：EFNFCustomer.dll5.2.2. VB程序开发规范参见附件VB代码规范.chm5.2.3. .Net程序命名空间规范U8 U8ERP的命名空间规范应遵守.Net Framework规范的，在分段部分不完全一样，U8的规范分为至少4段，即 UFIDA.U8.AppSvr.UI.1.分别为公司名段： UFIDA2.总产品名段：U83.小产品名段，服务框架：指定产品模块名称和服务的框架，如AppSvr-应用服务器，Workflow工作流服务器，Sale销售管理, Stock库存, Framework等含义比较清晰的词或词组，不要用很难理解的太简单或太冗长的词或词组4.界面层次名段：UIUser Interface，UIPUser Interface Processes，CIClient Side Interface，SIServer Side Interface，BFBusiness Faade，BOBusiness Object, DAOData Access Object, DOData Object5.对后续的段不做要求。5.2.4. .Net程序开发规范参见附件20031008 U8 NET 代码规范.pdf5.3. 数据库规范5.3.1. 二次开发命名规范n 凡是二次开发项目的数据库对象名前面必须增加项目简拼。以下例子以南孚电池为例类型规则例子表简拼_表名NFDC_Stock视图简拼_V_视图名NFDC_V_Stock存储过程简拼_P_存储过程名NFDC_P_Calc函数简拼_F_存储过程名NFDC_F_getAmount索引简拼_I_索引名NFDC_I_abc5.3.2. 字段类型n 对于数量、单价、金额字段应为decimal数据类型，如现存量表中的各累计字段、单据表中需回写累计值的字段、二次数据表中的累计字段等。n 对于各种单据表，为解决加锁问题可考虑加时间戳字段（timestamp, not null）n 建议不要使用float类型，否则可能会出现数据精度问题。n 如果是字符则必须是NVarchar或NChar类型，不要使用varchar和Char类型。建议减少使用NChar类型n 如果是主键则建议使用GUID类型，默认值是Newid()。5.3.3. 性能规范1. 在设计数据库中要考虑索引的建设问题。因为索引的建设和业务逻辑及性能及并发操作都有关系，因此在数据库设计中需要说明为什么建索引。哪种业务逻辑中需要建设索引。对每个字段只能建设一个索引，不得建设两个索引。在没有理由的情况下，不能随便建设索引。建设索引要具体情况具体分析，这方面要逐步加强对数据库基本理论中B+树及其上的并发操作的理解。但也有些一般性建议（这里需要说明的是：这不是规定）：1.1) 在数据量很大且涉及到 where 语句的情况下可以考虑对where语句所对应的字段建设索引（如 where col = hello 中的 col 字段），但是，col 字段的已经有的取值应该很广泛。1.2) 在涉及到 range 查询（如：WHERE sales_quantity BETWEEN 500 and 10001.2) ）的时候应该考虑建设蔟集索引。1.3) 在涉及到内联接的时候应考虑对两个联接字段建立索引；在涉及到左联接的时候应考虑对右面的字段建立索引；在涉及到右联接的时候应考虑对左边的字段建立索引。1.4) 在建立复合索引的情况下，如对（a, b）建立索引，可以应用对 a 字段的查询，如 where a = hello；当然也可以应用对 (a, b) 字段的查询，如 where a = hello and b = how；但是一般不适合对 b 字段的查询，如 where b = hello。2 SQL Server 中若在一个表中有主键，则对于这个主键自动建立簇集索引。在数据库设计中若只涉及到用主键进行单一行的检索，应该考虑对此主键不用蔟集索引。而将簇集索引用在别的字段上。3. 对于程序中涉及到多个表的联接的运算，应该对效率问题进行评估。在需要的情况下，应该考虑建设冗余表。特别是联接运算很频繁的情况下。在只涉及到内联接的情况下，为了效率问题要首先考虑建设索引视图。4. 在设计过程中，若出现需要根据一个表中的数据进行计算。而在实际应用中要频繁查询或调用此计算出来结果的情况下，要考虑建立索引视图。5. 数据库设计应尽可能满足第三范式。6. 在对操作系统和数据库配置进行修改时，请说明原因。一般情况下不建议对操作系统和数据库配置进行修改。7. 在设计数据库时，应考虑这种设计所面临的业务操作对并发的影响。在设计阶段避免死锁问题。每个数据库设计人员应该弄清楚什么是死锁，不清楚的请参阅任何数据库基本理论书籍或询问数据库组。8. 应考虑对频繁使用的中间结果建立冗余表进行存储。9. 每个数据库设计人员应参加数据库组组织的培训。10. 为了提高效率，需要其它组为本组建设冗余表，建设冗余字段，增加字段，建立触发器的，请尽可能在数据库设计初期发现。并在数据库设计中说明。由数据库组和总体技术部协调处理。要其它组为本组建立冗余表，且工作量较大的情况下，将由数据库组组织会议协商解决，并计算增加的工作量。5.4. COM+开发规范5.4.1. Com+组件规范n 无状态性开发的接口组件，最好不要具有公共属性，公共字段，不允许具有静态成员，静态方法。n 可序列化接口组件的接口类型必须可被序列化，及返回类型，参数类型必须是可被序列化的类型。特别注意的是，当你使用集合类型或DataSet的时候，你需要确保运行时，它里面所包含的类型必须能够被序列化。n out参数不允许使用out参数，可以使用ref参数代替。n 内部引用接口组件的接口上所引用的类型，最好在其他的程序集中实现，最好不要在自己程序集中实现，因为如果是在自己内部实现，如果使用了自定义类型，那就不能写在你的接口程序集里，因为如果这样，就增加了CI对程序集自身的依赖性，这样CI被部署到客户端，程序集自身也要被部署到客户端了，但是CI和程序集同名，无法放在一起。但是生成工具也会尝试生成，不过将略去初始值（只具有默认值），移除内部逻辑代码（方法，属性中的逻辑）。如果在接口程序集中声明了一些类型，而在接口类中没有引用，那么生成工具将忽略（移除）这些类型。n 类型忽略接口组件的一些基类型将会被忽略，比如ServicedComponent，MarshalByRefObject等系统基类型，他们的属性，方法不会被生成。n OneWay方法只能具有Void返回值，不能具有带ref参数的方法。5.4.2. Com+使用方式在你的接口类（如BF，BFDISPATCH）上标记特性ServiceVisible。你可以使用ServiceVisible(ServiceTypes.SingleCall)或ServiceVisible(ServiceTypes.Singleton)来指定是SingleCall对象，还是Singleton对象。默认（ServiceVisible()）是SingleCall。如ServiceVisible(ServiceTypes.SingleCall)public class BuesinessFacadeMethodTypes特性MethodTypes特性可以指定在方法上，构造参数可以使用MethodTypesOption枚举Sync ：只生成同步方法（默认，或不写）。Async：只生成异步方法，不包含同步方法。Both：同时提供同步方法和异步方法。OneWay：指定该方法为OneWay。如MethodTypes(MethodTypesOption.Sync)public DataSet GetData(string id).Context的使用如果你的接口程序集是从UFIDA.U8.Framework.BizBase.dll中的BFBase和BOBase或IcontextContainer继承或实现，那么就可以利用Context来传递自定义对象或数据（必须是可序列化的）。如,在客户端，对BF访问时，通过Add方法可以向Context传递额外的数据,该数据可以随着调用传递到服务端。BFObject bf = new BFObject();bf.context.Add(“key”,”value”);bf.DoSomrthing();object value = bf.context“key”在服务端的BF，你也可以取出并改变Context的值，然后让它原路返回到客户端。this.context“key” = “new value”;除此之外，SingleCall对象在服务端任何状态改变,客户端都无法直接得到。不过，需要注意的是，当你从BFBase继承的时候，服务端无法向客户端传递数据，因为你的组件是COM+组件，具有JIT特性，状态无法取得，除非你禁用了JIT（非常不推崇）。如果不是COM+组件（从BOBase或实现IContextContainer）,不会有此问题。客户端向服务端传递Context没有任何限制。5.4.3. Com+生成方式生成工具Generate.exeUsage:Generate source destination -keyfile: -lib:source:指定你的接口程序集位置destination:指定你的生成目标路径，工具将在你指定的目录下建立ClientInterface和ServerInterface两