过程与函数
数据库厂商为了凸现自身的优势，都提供了丰富且个性化的过程与函数。
为了提升产品的伸缩性和数据无关性，请不要使用与特定数据库相关的过程与函数，也不推荐采用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#的语法为：
| using system.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 hwnd,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可访问的包装类（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和密码正确。”，而不是仅仅说“更新数据库失败”。
显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。
异常处理的代码实例
推荐如下异常处理模式：
| void readfromfile ( string filename ) { try { // 读文件. } catch (fileioexception ex) { // 记载异常日志 // 重抛具有针对性的异常信息 throw; } } |
不推荐如下的异常处理模式：
| void readfromfile ( string filename ) { try { // 读文件 } catch (exception ex) { // 捕捉一般异常将让我们永远不知道到底是文件错误还是其他错误 // 隐藏异常将我们永远不知道有错误发生。 return ""; } } |
五、对象实例的申请与释放
.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。
如对本文有疑问， 点击进行留言回复！！
《CTF特训营》web部分读书笔记（二）跨站脚本攻击（XSS）
国密SM1\ SM2\ SM3\ SM4\ SSF33算法和国际RSA算法的对应关系
我要评论
网友评论