构造Bll和Dal：重在逻辑上分层，而不是物理上分层(一)
其实我的开发架构并不成熟，严格地说还很初级，这个问题本来轮不到我发言，但是看到那么多惨不忍睹的分层，实在忍不住说两句，就算是抛砖引玉吧，吴伟老兄出来说点吧，你老兄水深得很。
下面言归正传，这里只给我的出设计思路：
1、首先要说的是2007年年底我开始接手开发asp.net项目：我接手了一个拖了很久也没有完工的项目，简直就是petshop的翻版，当时我根本不懂什么是接口、反射、泛型,反正项目里都用上了，看得我云山雾罩，一开始我照葫芦画瓢写了一点，可是根本没法写下去，我以前的开发平台是vb6，架构是我自己设计的，没这么复杂啊，所以我停下来，通盘的审视代码，审视包括我以前用vb6开发的所有项目；
2、我总结出来：这些都是基于数据库的app，无论table和存储过程有多少，实质就几件事情：
  1）数据访问：通过一些参数执行了指定的存储过程
  函数定义：public static DataTable ExecuteSP（string pConn,Collection<Model.ParamInfo> pParams, string pSPName)
  2) 业务逻辑：在什么地方、什么时候、用什么参数，执行哪个存储过程
  待续……

------解决方案--------------------
是的，重在逻辑上分，而不是物理上。
有人以为在剑阁解决方案，再添加几个**BLL,**DAL的项目就算是使用三层架构了，这是错的。
还有，在开发中有些人为了模式而模式、为了反射而反射，让维护的人一头雾水，根本不需要那么做就可以实现的。
------解决方案--------------------
在一个软件的生命周期里，维护是占有很大比率的，怎么使软件的可维护性强，在软件开发时需要多多的考虑。。
------解决方案--------------------
物理上分层也很重要，可以大大方便部署和升级。
------解决方案--------------------
小型的电子商务的网站逻辑分层就够了
大型的就必须要物理上分层清楚，用户服务器，照片服务器这些
------解决方案--------------------
其实，主要的还是物理分层。
我们一般说的三层架构，都是代码上，部署上其实就2层，web application+Db
所以，对于大型的网站来说，都是扩展物理层来进行提升性能
个人觉得，代码上的分层，主要是用来维护和扩展的
------解决方案--------------------
楼主总结的不错
------解决方案--------------------
UP
------解决方案--------------------
学习
------解决方案--------------------
up
------解决方案--------------------
up