开发的技术规范与实践

1、ASP.Net平台开发的技术规范与实践精华总结本言语是以下是本人对.Net平台开发实践的一些点滴总结。这里的技术规范主要是开发过程的代码规范、数据库设计规范、Com和.Net互操作规范；实践精华是对技术实践过程中的部分总结。一、代码规范良好的代码风格来自于同一的代码规范。风格良好的代码不仅具备可读性和可维护性，同时也给人行云流水、赏心悦目之快感。据Microsoft公司统计，基于微软平台的开发中，有70-80%的印度工程师在完成同类算法或者模块时，使用的代码基本一致；而相同的调查中只有20%的中国工程师们是基本一致的。这说明我们的代码生产过程亟待规范。实义命名类型、变量、常量、方法等标识符一律

2、采用对应的英文实义；如果涉及到两个独立的实义单词，则中间用下划线间隔或者单词首字母大写（两种方式都可以）；如果标识符的长度超过了30个字母，则基本上以英文单词发音的重读音节取选出三个字母，如Repeater用rpt，Management用mgt。大小写规则目前一般有两种大小写规则：Pascal大小写形式，所有单词第一个字母大写，其他字母小写。Camel大小写形式，除了第一个单词，所有单词第一个字母大写，其他字母小写。类名使用Pascal大小写形式 public class HelloWorld（或者Hello_World，以下同，不再赘述） .方法使用Pascal大小写形式 public cl

3、ass HelloWorld（） void SayHello(string name) . 变量和方法参数使用Camel 大小写形式 public class HelloWorld（） int totalCount = 0; void SayHello(string name) string fullMessage = "Hello " + name; . 不要使用匈牙利方法来命名变量以前，多数程序员喜欢把数据类型作为变量名的前缀而m_作为成员变量的前缀。例如： string m_sName；int nAge；然而，这种方式在.NET编码规范中是不推荐的。所有变量都用Cam

4、el 大小写形式，而不是用数据类型和m_来作前缀。用name，address，salary等代替nam，addr，sal。别使用单个字母的变量象i，n，x 等。使用 index，temp等。用于循环迭代的变量例外： 如果变量只用于迭代计数，没有在循环的其他地方出现，允许用单个字母的变量命名，而不是另外取实义名。文件名要和类名匹配例如，对于类HelloWorld，相应的文件名应为helloworld.cs。缩进和间隔n 缩进用TAB，不用 SPACES。n 注释需和代码对齐。n 遵循VS2005的自动对齐规则，不要人为的调整。n 用一个空行来分开代码的逻辑分组。n 在一个类中，各个方法的实现体必

5、须用空行间隔，大括弧“”需独立一行。n 在每个运算符和括号的前后都空一格。如： If ( showResult = true ) for ( int i = 0; i < 10; i+ ) / 而不是： if(showResult=true) for(int i= 0;i<10;i+) / 良好的编程习惯n 避免使用大文件。如果一个文件里的代码超过300400行，必须考虑将代码分开到不同类中。n 避免写太长的方法。一个典型的方法代码在130行之间。如果一个方法发代码超过30行，应该考虑将其分解为不同的方法。方法名需能看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文

6、档来解释方法的功能了。n 一个方法只完成一个任务。不要把多个任务组合到一个方法中，即使那些任务非常小。n 使用C# 的特有类型，而不是System命名空间中定义的别名类型。如：int age;string name;object contactInfo; 而不是：Int16 age;String name;Object contactInfo;这么做是基于如下两点原因：（1）规范性和一致性；（2）便于跨语言平台的移植。n 别在程序中使用固定数值，用常量代替。别用字符串常数，尽量用资源文件。避免使用很多成员变量，声明局部变量，并传递给方法。不要在方法间共享成员变量，如果在几个方法间共享一个成员变

7、量，那就很难知道是哪个方法在什么时候修改了它的值。必要时使用enum，别用数字或字符串来指示离散值。 别把成员变量声明为 public或 protected。都声明为private 而使用 public/protected 的Properties。n 不在代码中使用具体的路径和驱动器名，使用相对路径，并使路径可编程。永远别设想你的代码是在"C:"盘运行。你不会知道，一些用户在网络或"Z:"盘运行程序。n 应用程序启动时作些“自检”并确保所需文件和附件在指定的位置。必要时检查数据库连接，出现任何问题给用户一个友好的提示。n 如果需要的配置文件找不到，应用程

8、序需能自己创建使用默认值。如果在配置文件中发现错误值，应用程序要抛出错误，给出提示消息告诉用户正确值。错误消息需能帮助用户解决问题。注释n 别每行代码，每个声明的变量都做注释。在需要的地方注释。n 可读性强的代码需要很少的注释，如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。行数不多的注释会使代码看起来优雅。如果因为某种原因使用了复杂艰涩的原理，必须为程序配备良好的文档和详细的注释。对注释做拼写检查，保证语法和标点符号的正确使用。 二、数据库设计规范表格分类与命名n 数据表的分类u 系统表支撑业务模型的数据表，如流程模型、系统管理相关表。u 业务表产品提供的针对业务的通

9、用功能模块相关表，如通用业务查询等。u 用户表用户二次开发使用的与具体业务相关的数据表。n 数据表的命名u 所有表格命名一律以字母“T”开头（Table），并且用实义单词以下划线“_”间隔。u 系统表系统表前缀为：TSYS_u 业务表前缀为：TBIZ_u 用户表由用户自行定义，但是建议不要与系统表和业务表的命名规则重复。n 字段的命名字段的命名规则参照代码标识符的命名规则，但是注意避开数据库的保留字。比如不要采用这样的字段名：index，field，password，id，Oracle，SQL等等。对于涉及到技术核心的系统表，为了防止剖析，建议采用类似“F1，F2，F3Fn”的方式命名。但是不

10、要采用“F0”，因为这个名称在某些数据库中不被允许，比如Interbase。索引的建立n 索引是一把双刃剑，索引将提高查询的效率，但是却降低了insert/delete/update 的效率。通常情况下，对数据的编辑频度和时限要求远远低于对数据库的查询要求，因此对于记录很多且频繁查询的数据表，必须建立索引。n 大多数数据库为主键字段自动创建索引，注意为外键创建索引。n 不要索引大字段，这样作会让索引占用太多的存储空间。n 尽量不要索引频繁编辑的小型表。n identify字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。如果考虑支持多数据库，建议主键采用程序生成的唯一值。n 如果一

11、个大型表需要频繁的做insert/delete/update操作，同时也需要做高并发量的查询，那么建议根据数据的访问频度对表作拆分，而后建立索引。过程与函数数据库厂商为了凸现自身的优势，都提供了丰富且个性化的过程与函数。为了提升产品的伸缩性和数据无关性，请不要使用与特定数据库相关的过程与函数，也不推荐采用Store Procedure，建议使用应用服务器的中间层业务对象。字段/域的定义n 尽量避免使用Blob，如果一定要用，请不要索引blob，并且不要定义多个blob。n 不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。n 对于确定长度的串，请固定

12、字段类型的长度，如char（80），不要采用varchar。n 对于值类型字段，请使用对应的数据库值类型，而不要用字符串。三、Com和.Net互操作规范.NET 技术已经成为微软平台的主流，但是在Win32时代开发了很多COM、DCOM组件，由于在开发COM组件时投入了大量的人力、财力，如何在.NET环境下重用这些COM组件就显得更有意义。.NET支持运行时通过COM、COM、本地WinAPI调用与未托管代码的双向互操作性，要实现互操作性，必须首先引入.NET Framework的 System.Runtime.InteropServices命名空间。C#的语法为： using System.

13、Runtime.InteropServices; （1）.NET访问API .NET允许C访问未托管的DLL的函数。如要调用Windows User32.dll的MessageBox函数：int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType) 可以声明一个具有DLLImport属性的static extern方法： using System.Runtime.InteropServices； DllImport(“user32.dll”) static ertern int MessageBox(int hwn

14、d,string text,string caption,int type); 然后在代码里面直接调用就可以了。这里要注意在调用返回字符串的API中使用StringBuilder对象。 （2）.NET访问COM组件 从.NET调用COM组件比较容易，只要使用tlbimp.exe产生COM的装配形式的WarpClass，然后在.NET项目中调用即可。注意COM的类型信息通过Type Library文件描述，.NET装配件是自描述的。Tlbimp的作用是从COM组件及其类型信息中产生自描述的装配件。1编写Com组件编译生成一个ComAccount.dll。2. 产生.NET可访问的包装类（asse

15、mbly），使用TlbImp.exe产生.NET装配件。 TlbImp /out：NetAccount.dll ComAccount.dll ( 3 )在.NET代码中访问 .NET代码只需引用NetAccount.dll,就可以像访问.NET的装配件一样访问COM组件。四、异常处理异常处理的原则在应用程序级（线程级）错误处理器中处理所有的一般异常。遇到“意外的一般性错误”时，此刻错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或用户选择“忽略并继续”之前记录错误信息。n 不必每个方法都用try-catch，当特定的异常可能发生时才使用。比如，当写文件时，处理异常FileIOExcept

16、ion。别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。这将有助于找出哪一段代码产生异常，并给用户发出特定的错误消息。如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。n 在开发阶段，不必在所有方法中捕捉一般异常。刻意的放纵异常，将帮助在开发周期发现大多数的错误。异常处理的提示n 不要捕捉了异常却什么也不做，看起来系统似乎在正常运行。如果这样隐藏了一个异常，将永远不知道异常到底是否发生，为什么发生。发生异常时，给出友好的消息给用户。但要精确记

17、录错误的所有可能细节，包括发生的时间，和相关方法，类名等。永远别用像“应用程序出错”，“发现一个错误”等错误提示消息，而应给出类似“更新数据库失败，请确保登陆id和密码正确。”之类的具体消息。显示错误消息时，还应提示用户如何解决问题。如：“更新数据库失败，请确保登陆id和密码正确。”，而不是仅仅说“更新数据库失败”。n 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。异常处理的代码实例推荐如下异常处理模式：void ReadFromFile ( string fileName ) try / 读文件. catch (FileIOException ex) / 记载异

18、常日志 / 重抛具有针对性的异常信息 throw; 不推荐如下的异常处理模式：void ReadFromFile ( string fileName ) try / 读文件 catch (Exception ex) / 捕捉一般异常将让我们永远不知道到底是文件错误还是其他错误 / 隐藏异常将我们永远不知道有错误发生。 return "" 五、对象实例的申请与释放.Net平台的垃圾回收机制，可以自动的dispose不再引用的对象实例，所以很多开发人员并不主动释放申请的对象资源。事实上，在对象的生命周期结束之前是不会被释放的。但是，很多时候当对象处于生命周期之内时，我们不再使用它，以便释放资源提升系统效率。因此，主动释放申请的资源显得很有必要。永远不要把力所能及的事情交给操作系统，及时释放不再使用的资源是一个好习惯。六、数据库访问数据库访问永远是系统的瓶颈，选择高效、稳健的数据库访问模式是产品性能的基础保证。n 永远不要假设你的应用系统构建与某个数据库之上，因此必须有统一的、透明的数据库访问机制。采用ADO.Net访问数据库基于效率和稳定性的考量，采用微软平台原生的数据库访问模式ADO.Net。使用ADO.Net