构造Bll和Dal：重在逻辑上分层，而不是物理上分层(二)
http://topic.csdn.net/u/20100130/12/50c13651-b3e5-450c-9042-568541d182cc.html
接上

  2) 业务逻辑：在什么地方、什么时候、用什么参数，执行哪个存储过程 
  我们给Bll的对象起个名字：MyMethod，无非就是这些方法：
  MyMethod.CreateInputView():创建用户输入视图；
  MyMethod.BindInputView(): 绑定用户输入视图；
  MyMethod.CreateOutputView():创建输出视图；
  MyMethod.BindOutputView():绑定输出视图；
  MyMethod.ExecuteSP()：调用抽象的数据访问（增删改查）

3、至此，我发现这种设计具有以下特征：
  1）代码量少的可怜，不会随项目规模增加而增加；
  2）项目无关、数据无关，不涉及具体的字段和表；
  3）界面上实例化几个MyMethod就决定了他能干什么，
4、实现这种设计的关键在于把传统的有数据库驱动开发的模式改变成有项目文档驱动开发的模式：
  工序1：编写项目文档（建模）；
  工序2：生成UI，测试原型，用户预览；
  工序3：重复1、2；
  工序4：生成db、测试App、交付app以及模型副本；


------解决方案--------------------
不懂帮顶
------解决方案--------------------
我命令我的小组成员把逻辑层,业务层,实体类和数据访问层写在一个类库里面.仅用名字相区别.
------解决方案--------------------

探讨

我命令我的小组成员把逻辑层,业务层,实体类和数据访问层写在一个类库里面.仅用名字相区别.

------解决方案--------------------
楼主的业务逻辑层说的不够全面，
业务逻辑，取到数据后，如果需要对数据进行处理，可以在业务逻辑层处理。

------解决方案--------------------

探讨

楼主的业务逻辑层说的不够全面，
业务逻辑，取到数据后，如果需要对数据进行处理，可以在业务逻辑层处理。

------解决方案--------------------
楼主你怎么没有把业务规则放一层啊! 好比做同样的事,但是要求不一样你该怎么办
------解决方案--------------------
up

------解决方案--------------------

探讨

引用:
我命令我的小组成员把逻辑层,业务层,实体类和数据访问层写在一个类库里面.仅用名字相区别.

這樣也行？怕得成千上萬行了吧，看著不累？

------解决方案--------------------

探讨

引用:
引用:
我命令我的小组成员把逻辑层,业务层,实体类和数据访问层写在一个类库里面.仅用名字相区别.

這樣也行？怕得成千上萬行了吧，看著不累？

请注意是一个类库,而不是一个文件

------解决方案--------------------
up
------解决方案--------------------
想法很好,需要时间检验
文档从功能上来说就是一个巨大的配置文件,因为所有的方法基本上没有与具体业务逻辑相关,这样每个方法都要读配置,实际上是把原本出现在程序中的代码转换到了文档中,其执行效率可想而知