用友开发,用友二次开发U8二次开发规范。

U8二次开发规范摘要目前U8产品越来越庞大，提供的应用与服务也越来越多样化。

公司整体的发展战略要求U8要成为一个能支持规模化交付的产品。

为了达到这样的目标，仅仅通过我们的水平产品是无法满足客户的行业化、个性化的要求的。

所以二次开发就成为一个能满足可以要求的填充剂，填补水平产品与客户的需求中的差异的空隙。

什么是二次开发？二次开发是与一次开发是相对应的，所以凡是由U8产品开发部提供的U8产品、套件以外的都应属于二次开发的产品。

从这个定义出发以下行为属于开发开发范畴。

⏹分公司、大区的基于U8的开发行为。

⏹第三方合作伙伴的基于U8的开发行为。

⏹行业开发本部基于U8产品的开发行为。

主要的开发模式。

1.独立开发模式，独立于产品●模式描述：在开发过程中基本不利用U8产品的构件（只利用登录构件），开发成果形成单独的可执行文件及动态库，模块不需要与U8门户程序集成，二次开发模块的权限设置、功能升级、部署均独立于产品。

●优点：对产品的影响小，产品可升级性强，不受产品功能制约。

模块功能灵活度大，能够实现很复杂的功能。

●缺点：二次开发的模块产品风格与U8 产品风格差距较大，产品中一些很完善的功能（权限、打印、格式设置、输出等）不能被二次开发利用，打印、输出等基础功能需要重新开发，开发效率低。

●注意问题：如果使用了U8登录构件，在产品升级后，应测试登录构件是否向下兼容，如果不兼容要根据新版登录构件的使用文档对二次开发程序的登录部分作修改。

●禁止行为：为最大限度的保证产品的可升级性，禁止直接修改产品的系统数据表、视图、存储过程等数据库对象。

●适用需求：与产品关联度小，二次开发的功能与产品相对独立，属单独的功能需求，不影响产品的业务流程，但允许由产品中取数。

例如：在U8产品的基础上增加提成管理系统。

2.通过产品插件接口开发模式●模式描述：此模式的开发是利用产品开放的插件接口对原产品模块做功能扩展。

开发成果形成单独的动态链接库，模块功能不能单独使用，一般由产品模块通过插件接口依据插件注册信息自动调用。

二次开发模块的权限设置、功能升级、部署均独立于产品。

●优点：利用插件方式开发，对产品影响小，产品可升级性强。

插件机制可以规范二次开发模块的开发方式，插件产品重用性强，功能配置灵活。

●缺点：受产品插件接口开放程度的限制，目前只有库存模块提供了二次开发插件接口，其他模块还未提供，而库存模块也只提供了单据保存、审核、明细行双击等部分事件的插件接口，面对用户多种多样的二次开发需求，产品的插件接口开放程度还很不够。

●注意问题：插件开发应完全符合U8产品提供的插件二次开发规范，尽量采用与产品一致的开发语言(VB6.0)做插件，保证插件数据库操作与产品的数据库操作在同一事务中。

●禁止行为：●适用需求：客户需求与产品模块结合紧密，需要基于某一产品模块做功能扩展，尽量采用插件方式。

目标针对目前的开发现状现我们分几个方面制定开发行为规范，以此规范开发人员的行为，告诉二次开发人员哪些行为是安全的，哪些行为是危险的。

U8二次开发行为规范1、独立模块开发规范利用VB或其他开发工具开发独立的模块是目前一般的开发行为，这种开发方式对U8的依赖最低，藕合度小，受到的升级的影响也最小。

在目前U8开发性比较低的情况下这是一种合理的选择。

但是这种方式无法做到与系统的无缝结合。

在UI的风格上也有可能造成较大的差异。

开发分以下阶段进行。

●需求调研阶段：调研规范：二次开发调研不同于产品功能调研，客户提出的需求有可能代表一类行业的应用方式，但也有可能为该客户独有的需求。

要求二次开发人员必须仔细分析客户提出需求的原因，首先确定是否可以通过软件以变通的方式实现用户的需求，确认没有其他解决方案后才可定义为二次开发需求。

需求规范：对于典型行业的二次开发的需求，且符合集团行业开发部做行业项目支持的条件，需要遵循行业开发部提供的二次开发需求模板编写二次开发需求文档。

需求文档要严格按照模板内容逐项编写，特别要注意业务算法、数据精度、效率要求等设计相关的内容一定要作深入调研。

对于分公司负责开发的项目，也可以参照行业开发部提供的二次开发需求模版进行需求编写，作为下一步设计、研发的指导性文档。

二次开发需求完成后，首先要经过用户确认，然后提交项目组召集相关需求、设计、研发人员进行需求评审，需求确认后即可进行设计、研发工作。

●设计阶段：设计原则：1)需求设计一致性：二次开发模块设计必须满足软件需求说明书的所有要求，包括所有功能要求、性能要求和其它要求。

软件需求说明的变化与软件设计说明书的变化必须保持一致。

变化不能随意进行，应置于严格的配置管理之下，对于软件需求确认后的变更要严格控制，避免二次开发周期过长。

2)数据结构独立性：对于二次开发的模块禁止修改产品系统表数据结构及相关视图、存储过程、触发器等数据对象，最大限度的保证产品的可升级性。

二次开发新建数据对象的命名规则应遵从二次开发数据对象命名规范。

3)数据一致性、合法性：设计过程中要考虑二次开发模块与相关产品模块数据的一致性。

首先要保证产品的数据安全，尽量避免直接新增或修改系统数据表的记录。

如果确实需要维护系统数据表的记录，尽量采用产品开放的业务组件操作数据库记录，保证数据的完整性、合法性。

4)产品化原则：对于有可能产品化或插件化的二次开发需求，在设计时要考虑二次开发模块的通用性、可推广性。

二次开发模块要达到易安装、易使用、易维护的设计要求。

尽量使用U8产品使用的构件，需要向集团申请模板编号、模块编号，避免和产品冲突。

●编码阶段：1)尽量采用与产品模块开发语言一致的开发语言。

2)首先VB语言编码规范遵循U8产品使用的VB编码规范,见附件。

利于二次开发模块的产品化。

其他开发语言编码规范也可参照VB的编码规范执行。

3)其次，作如下补充：注释规范：模块开头说明：增加“相关产品模块及本模块与产品模块的关系”、“作者单位”、“作者电子邮箱”、“适用产品版本”4)配置管理工具可采用SourceSafe作配置管理。

2、二次开发项目命名规范U8中使用的产品有自己的规范，产品以大写的英文字母表示如AR应收系统，该产品下的子产品用产品的字母开头后面接字母或数字AR101设置，AR10101初始设置，在门户的中的显示为树的形式，其中AR为AR101的父节点，AR101为的父节点。

其他新产品的起名，或二次开发的产品的起名必须遵循上面的规则，并不能和已有的产品名称相重，下面是在U8中以使用的产品名称及相应的对应的关键字。

对于二次开发项目需要确认项目编号，在以后定义菜单、组件名称、数据库命名时必须在相关的位置遵循此规范。

规范如下：客户化开发项目的开头必须是EF，然后是项目名，如EFNF表示是二次开发南孚项目。

此长度不能超过6位。

3、二次开发菜单命名规范✧二次开发项目的菜单命名开头是项目名如：EFNF。

✧一级产品名称长度为2位，如：EFNF01。

✧二级产品名称长度为2位, 如：EFNF0101。

✧三级产品名称长度为2位, 如：EFNF010101。

✧无论是独立的二次开发子产品还是在标准产品下增加二次开发菜单都要求遵循此规范。

✧总长度为不能超过14位。

4、二次开发权限命名规范权限和菜单命名要求一致，字面必须大写。

5、关键项目命名规范【UAP项目】UAP产品在使用前都需要先定义一个项目，此项目必须遵循二次开发项目命名规范。

【单据、打印模板】单据打印模板数据的CardNum字段的前缀必须是项目编号，后面的预置可以自由定义。

如：EFNF001【栏目模板】栏目预置在Meta库中，其cKey字段的前缀必须是项目编号，后面的预置可以自由定义,cProjectNO字段值不能是U870，必须使用项目号。

如：EFNF001【过滤模板】过滤预置在Meta库的flt_defineMeta_Base表中，其FilterID字段的前缀必须是项目编号，后面的预置可以自由定义,ProjectNO字段值不能是U870，必须使用项目号。

如：EFNF001【数据引擎】✧实体名称必须以项目号和下划线作为前缀，并以ENT作为结尾。

如EFNF_CGDD_ENT✧业务对象名称必须以项目号和下划线作为前缀，并以BO作为结尾。

如EFNF_CGDD_BO【参照】✧参照的编号必须以项目编号和下划线为开头如：EFNF_Customer。

U8的开发规范1、代码规范1.1、VB程序组件命名规范VB组件命名需要在组件前面增加项目编号，如：EFNFCustomer.dll1.2、VB程序开发规范参见附件《VB代码规范.chm》1.3、.Net程序命名空间规范U8 U8的命名空间规范应遵守.Net Framework规范的，在分段部分不完全一样，U8的规范分为至少4段，即EF.项目号.U8.1.分别为二次开发名段：EF2.总产品名段：项目号.U83.小产品名段，服务框架：指定产品模块名称和服务的框架，如AppSvr--应用服务器，Workflow工作流服务器，Sale销售管理, Stock库存, Framework等含义比较清晰的词或词组，不要用很难理解的太简单或太冗长的词或词组4.界面层次名段：UI—User Interface，UIP—User Interface Processes，CI—Client Side Interface，SI—Server Side Interface，BF—Business Façade，BO—Business Object, DAO—Data Access Object, DO—Data Object5.对后续的段不做要求。

1.4、.Net程序开发规范参见附件《20031008 U8 NET 代码规范.pdf》2、数据库规范参见数据库开发文档。

3、COM+开发规范3.1、Com+组件规范⏹无状态性开发的接口组件，最好不要具有公共属性，公共字段，不允许具有静态成员，静态方法。

⏹可序列化接口组件的接口类型必须可被序列化，及返回类型，参数类型必须是可被序列化的类型。

特别注意的是，当你使用集合类型或DataSet的时候，你需要确保运行时，它里面所包含的类型必须能够被序列化。

⏹out参数不允许使用out参数，可以使用ref参数代替。

⏹内部引用接口组件的接口上所引用的类型，最好在其他的程序集中实现，最好不要在自己程序集中实现，因为如果是在自己内部实现，如果使用了自定义类型，那就不能写在你的接口程序集里，因为如果这样，就增加了CI对程序集自身的依赖性，这样CI被部署到客户端，程序集自身也要被部署到客户端了，但是CI和程序集同名，无法放在一起。

但是生成工具也会尝试生成，不过将略去初始值（只具有默认值），移除内部逻辑代码（方法，属性中的逻辑）。

如果在接口程序集中声明了一些类型，而在接口类中没有引用，那么生成工具将忽略（移除）这些类型。