对于数据分层的概念想必大家都看的很多了.在这里我就不再罗嗦..不说理论.只说实际.以下内容大部分是以ASP.NET角度出发.

首先:采用分层前,要考虑自己的需求.不要为了跟潮流,看别人分层我也要分层.这样的思想只会使自己更麻烦.我的建议,对于小项目,如果后期需要周期性的扩展,或者需求会经常改变.可以考虑分层实现..如果只是一个中小企业的网站.需求经常不会改变的.而且大部分的功能都是以前做过的,完全可以直接ASPX+ASPX.CS..

其次:对于分层没有一个标准.也没有一个硬性的规则.分层的主要是目的是让项目能够灵活,便于管理和扩展.分层的后代码应该是很少见到甚至见不到重复出现的代码片段.我就曾见过有的分层,每个层中都会有重复的功能或者类似的功能代码..而这些重复的功能模块只是因为传递的参数不同或者返回的参数不同而重新写了类似的代码..这样的代码完全可以分割为更小的模块.重新封套再组合..比如,饮料,茶水,他们虽然是不同的产品,但是他们确有同样的物质成分--水..
饮料可以分为:水和其他物质,
茶水可以分为:水和茶叶
这样拆分后就看出来他们共同的物质是:水!面向对象编程的思想也是这样..要做到最大的灵活度.就需要从功能上分割.

最后:对于ASP.NET来说,决定性能的关键就是网络传输的大小,传输的Data越大则性能消耗就越大.而优化性能的关键是对数据库的优化.我的建议是:尽可能的将你的SQL语句缓存,一起执行.避免下列行为的发生:

SqlCommand com = new SqlCommand("select * from table1",conn);
dr = com.executeReader();
com.CommandText = "select * from table2";
dr = com.executeReader();
com.CommandText = "select * from table3";
dr = com.executeReader();

这样频繁的读取数据是很消耗资源的..其实完全可以写成存储过程,然后一次执行赋予SqlDataReader或者DataSet..如果SqlDataReader自身有多张表的话,SqlDataReader的NextResult()方法可以操作多表.
对于数据库层中的传输,大家用DataSet比较多.如果需要通过DataSet往返数据层与业务层..可以考虑使用DataSet的GetChanges()函数.他返回DataSet中只改变的记录..然后将改变后的DataSet用Merge()添加到业务层中..

以上内容只是为了说明:不要人家说好就是好,人家能用的我也能用,关键是要适合自己,能适合自己的需求才是最重要!

今天暂时写到这里,过几天找时间再继续写..今天可是冒着生命危险写的哦..

链接:我对分层的理解(二)