对.Net平台开发实践的总结
| 的代码需要很少的注释，如果所有的变量和方法的命名都很有意义，会使代码可读性很强并无需太多注释。行数不多的注释会使代码看起来优雅。
如果因为某种原因使用了复杂艰涩的原理，必须为程序配备良好的文档和详细的注释。 对注释做拼写检查，保证语法和标点符号的正确使用。
二、数据库设计规范 表格分类与命名 数据表的分类 系统表 支撑业务模型的数据表，如流程模型、系统管理相关表。 业务表 产品提供的针对业务的通用功能模块相关表，如通用业务查询等。 用户表 用户二次开发使用的与具体业务相关的数据表。 数据表的命名 所有表格命名一律以字母“T”开头（Table），并且用实义单词以下划线“_”间隔。 系统表 系统表前缀为：TSYS_ 业务表前缀为：TBIZ_ 用户表由用户自行定义，但是建议不要与系统表和业务表的命名规则重复。 字段的命名 字段的命名规则参照代码标识符的命名规则，但是注意避开数据库的保留字。比如不要采用这样的字段名：index，field，password，id，Oracle，SQL等等。 对于涉及到技术核心的系统表，为了防止剖析，建议采用类似“F1，F2，F3……Fn”的方式命名。但是不要采用“F0”，因为这个名称在某些数据库中不被允许，比如Interbase。 索引的建立 索引是一把双刃剑，索引将提高查询的效率，但是却降低了insert/delete/update 的效率。 通常情况下，对数据的编辑频度和时限要求远远低于对数据库的查询要求，因此对于记录很多且频繁查询的数据表，必须建立索引。 大多数数据库为主键字段自动创建索引，注意为外键创建索引。 不要索引大字段，这样作会让索引占用太多的存储空间。 尽量不要索引频繁编辑的小型表。 identify字段不要作为表的主键与其它表关联，这将会影响到该表的数据迁移。如果考虑支持多数据库，建议主键采用程序生成的唯一值。 如果一个大型表需要频繁的做insert/delete/update操作，同时也需要做高并发量的查询，那么建议根据数据的访问频度对表作拆分，而后建立索引。 过程与函数 数据库厂商为了凸现自身的优势，都提供了丰富且个性化的过程与函数。 为了提升产品的伸缩性和数据无关性，请不要使用与特定数据库相关的过程与函数，也不推荐采用Store Procedure，建议使用应用服务器的中间层业务对象。 字段/域的定义 尽量避免使用Blob，如果一定要用，请不要索引blob，并且不要定义多个blob。 不要使用日期字段，改用字符串char(19)替代，如：2008-12-09 12:22:08。 对于确定长度的串，请固定字段类型的长度，如char（80），不要采用varchar。 对于值类型字段，请使用对应的数据库值类型，而不要用字符串。
三、Com和.Net互操作规范 .NET 技术已经成为微软平台的主流，但是在Win32时代开发了很多COM、DCOM组件，由于在开发COM组件时投入了大量的人力、财力，如何在.NET环境下重用这些COM组件就显得更有意义。 .NET支持运行时通过COM、COM＋、本地WinAPI调用与未托管代码的双向互操作性，要实现互操作性，必须首先引入.NET Framework的 System.Runtime.InteropServices命名空间。 C#的语法为：
1) .NET访问API .NET允许C＃访问未托管的DLL的函数。如要调用Windows User32.dll的MessageBox函数： int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType) 可以声明一个具有DLLImport属性的static extern方法：
然后在代码里面直接调用就可以了。这里要注意在调用返回字符串的API中使用StringBuilder对象。 2) .NET访问COM组件 从.NET调用COM组件比较容易，只要使用tlbimp.exe产生COM的装配形式的WarpClass，然后在.NET项目中调用即可。 注意COM的类型信息通过Type Library文件描述，.NET装配件是自描述的。Tlbimp的作用是从COM组件及其类型信息中产生自描述的装配件。 1．编写Com组件 编译生成一个ComAccount.dll。 2. 产生.NET可访问的包装类（assembly），使用TlbImp.exe产生.NET装配件。 TlbImp /out：NetAccount.dll ComAccount.dll 3．在.NET代码中访问 .NET代码只需引用NetAccount.dll,就可以像访问.NET的装配件一样访问COM组件。
四、异常处理 异常处理的原则 在应用程序级（线程级）错误处理器中处理所有的一般异常。遇到“意外的一般性错误”时，此刻错误处理器应该捕捉异常，给用户提示消息，在应用程序关闭或用户选择“忽略并继续”之前记录错误信息。 不必每个方法都用try-catch，当特定的异常可能发生时才使用。比如，当写文件时，处理异常FileIOException。 别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。这将有助于找出哪一段代码产生异常，并给用户发出特定的错误消息。 如果应用程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。 在开发阶段，不必在所有方法中捕捉一般异常。刻意的放纵异常，将帮助在开发周期发现大多数的错误。 异常处理的提示 不要捕捉了异常却什么也不做，看起来系统似乎在正常运行。如果这样隐藏了一个异常，将永远不知道异常到底是否发生，为什么发生。 发生异常时，给出友好的消息给用户。但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。 永远别用像“应用程序出错”，“发现一个错误”等错误提示消息，而应给出类似“更新数据库失败，请确保登陆id和密码正确。”之类的具体消息。 显示错误消息时，还应提示用户如何解决问题。如：“更新数据库失败，请确保登陆id和密码正确。”，而不是仅仅说“更新数据库失败”。 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。 异常处理的代码实例 推荐如下异常处理模式：
不推荐如下的异常处理模式：
五、对象实例的申请与释放 .Net平台的垃圾回收机制，可以自动的dispose不再引用的对象实例，所以很多开发人员并不主动释放申请的对象资源。事实上，在对象的生命周期结束之前是不会被释放的。 但是，很多时候当对象处于生命周期之内时，我们不再使用它，以便释放资源提升系统效率。因此，主动释放申请的资源显得很有必要。 永远不要把力所能及的事情交给操作系统，及时释放不再使用的资源是一个好习惯。 六、数据库访问 数据库访问永远是系统的瓶颈，选择高效、稳健的数据库访问模式是产品性能的基础保证。 永远不要假设你的应用系统构建与某个数据库之上，因此必须有统一的、透明的数据库访问机制。 采用ADO.Net访问数据库 基于效率和稳定性的考量，采用微软平台原生的数据库访问模式ADO.Net。使用ADO.Net可以通过OLEDB和ODBC两种模式访问数据库，我们建议使用数据库厂商提供的OLEDB模式，这种模式绕过了ODBC，使得数据库的游标性能大大提升，效率更佳。 不使用第三方的数据持久层使用类似于Nhibernate之类的第三方数据持久层工具虽然可以提高开发的效率，但是却降低了系统的性能和弹性。性能对于产品而言，远远比开发效率重要的多，况且基于VS2005的开发，效率不是问题。请记住：第三方的工具永远不能成为你的产品核心技术；数据访问机制是系统的效率瓶颈，对 使用自主产权的数据对象 直接采用ADO.Net封装最底层的数据访问方法：插入、删除和更新，以及事务管理等；客户端和服务器端采用相同的数据访问机制，并设立连接缓冲池提升数据访问效率。 七、分布式事务管理 对于多层分布式应用而言，数据库事务呈现出“远程、分布”的特色，导致事务难以管理。 对于Ado.Net而言，事务绑定了数据库连接，因此必须在数据访问对象中对每一个数据库连接管理各自的事务或嵌套事务。如果要访问数据库，服务器上的数据访问对象将自动分配一个特定的连接，根据该连接ID执行数据操作；无论该事务分布于多少个远程客户端进程，服务器数据对象只需要锁定连接ID即可轻松进行事务管理。 八、智能客户端 智能客户端是易于部署和管理的客户端应用程序，它综合了瘦客户端和胖客户端的优点，通过统筹使用本地资源和到分布式数据资源的智能连接，提供快速响应的和丰富的交互式体验。 智能客户端分为Windows Form，Office Client，Mobile Client三种类型，具有如下特点： 利用本地资源 利用网络资源 支持偶尔连接的用户 提供智能安装和更新 提供客户端设备灵活性 .NET 框架基类库内嵌了支持智能客户端的丰富程序集，通过使用公共语言运行库 (CLR)，可以利用任何受到 .NET 支持的语言来开发智能客户端。 智能客户端是瘦客户段的强大替代品，也是微软推荐的客户端模式。尽量使用智能客户端而不要使用浏览器。如果可以，请把你的客户端系统构建在Office平台上，如Outlook。 |
||||
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
