.NET开发的一些积累
ASP.NET项目开发一些琐碎的积累
1.过滤危险的字符串，诸如“=”、“>”等可能会诸如数据库的危险字符串，我看过很多人做的网页仅仅进行客户端脚本验证是不够的。必须在服务器段的后台代码里面也进行数据验证，我曾经编写过一个程序可以绕过脚本验证提交表单。
2.判断字符串可否转换成整形、字符型、还是浮点型等
3.错误处理，如果简单的站点需要配置一下写一下Application_Error事件就可以了。复杂的站点需要编写日志类，来处理
使用记录站点出现的异常。
4.经常用地的Request.QueryString操作。最好写成公共的处理方法以返回需要的类型数据。具体可以参考动网论坛的.
5.根据站点的规模以及功能划分出几个区域分别基础Page类。诸如：后台管理界面、用户中心、帮助中心、Ajax处理。还需要注意网页内容是否需要在客户端存储。如果开发的项目自己公司的同时需要进行维护，同时应该考虑Js脚本文件的变化，因为如果需要增加JS代码可能每个页面都要增加，所以最好的输出脚本的方式就是定义公共的类。我们所经常用到Page对象的ClientScript属性并不能完成所有功能的脚本注册，如果你想写一个公共的Page类并且向头部输出js,那ScriptManger是不能完成的。它仅限于向Body元素内部输出脚本。一般我会这个往头部添加脚本
js.Attributes.Add("type", "text/javascript");
js.Attributes.Add("src","test/123.js");
this.Page.Header.Controls.Add(js);
以后如果每个页面都需要添加Js文件可以直接在基类中添加就可以了。
这个道理同样适用于数据库开发，比如PetShop中用到了四个数据库分别存放主题数据、订单中心、客户数据等根据不同的模块来划分数据库。划分的原则就是：表直接联系特别密切的划分到一个数据库中，比较松散的划分的两个数据库中。这样便于后期的管理与维护（当然，如果是租用空间还是就不要考虑这个了，因为托管服务器买数据库也需要钱的。。多个数据库多点投入，这样的客户还是用一个省事）。
6.经常用的的消息弹出框最好也单独写一个类来进行处理。还有获取主机IP、简体字繁体直接的转换、字符的加密解密、Cookie操作、文件操作、URL操作（获取根目录URL等，经常在用户控件中会用到，一个用户控件可能会被几个不属于一个
目录层次的Page调用，如果该用户控件上有图片、JS文件路径就会需要获取根目录的URL）
7.必须了解软件的运行环境是在机房托管的服务器还是租用的空间？托管的服务器开发限制较少。如果是租用的空间限制比较大，好多功能不能用，如果是机房托管的服务器灵活性就比较大了。
8.注意在代码中应用的sql语句,注意变量的类型与sql中数据类型相对应，如
string sql="SELECT * FROM [Customer] customerID="+a.ToString();
编译的时候并没有错,执行的时候也就有问题了。。进入SQL中执行的时候“45454”就会被解释成整形了。如果超出数据范围就会出现异常。这时候就需要的了''(单引号)
string sql="SELECT * FROM [Customer] customerID='"+a.ToString()+"'";
9.编码过程中最大限度的实现功能的模块化。如果一个页面上有查过两个以上的功能区域，做好把每个区域做成用户控件，用户控件之间尽可能少的了解的其他用户控件。可以通过session、Cookie 来共享数据。模块化不仅有利于代码移植，而且便于代码修改于阅读。
10.网站设计过程中应该仔细的考虑缓存的设计，这样可以大幅度的提高性能。一般来说读取数据库比读取普通硬盘上的文本文件要慢一些，所以我经常缓存一些XML文件到Cache中。测试一下就会发现性能提升时很明显的事情。
11.设计的时候针对不同的项目必须考虑其变化点。我经常做一些电子商务平台的软件。最大的变化点就业经常变更的销售策略，从配送发货到商品打折，经常会变化，对于项目来说就是业务逻辑层经常地变动。所以写代码的时候最好可以把变化点进行分离出来，业务的逻辑的处理最好编写单独的模块,经常用到的字符也可以转换成一个类的常量单独存储。
12.对于数据库的完整性虽然约束不支持跨数据的，但是触发器却支持。当需要数据实现联动的时候处理用C#代码来针对每个表来处理之外，也可以采用触发器实现多个表之间的数据同步。但是触发器是在其他外键约束没有作用的是时候才会采用的，因为触发器作为约束来使用并没有外键那么强。
13.好的编码规范是才能保证良好的程序结构与可读性。如果开发项目前做编码规范那么即使代码结构再好，其可读性也会大大降低。多说一下数据库的命名吧。一般的一个中型项目少说也得100多个表，如果名字命名的不好后期维护人员看着是很头痛的。一般表名最好采用前缀、后缀来安功能或区域来划分。存储过程最好采用表名+“_”+动词的方式来命名便于以后维护，名字不要太短。
