关于静态与动态的问题,请大家提提建议和意见

Question

我的项目是这样一种模式(通用层就不说了)
首先,我把属性和方法彻底分离到不同的类中:
Model.DeptInfo 只有属性,并且没有静态成员,需实例化调用
DAL.DeptDA 只有数据访问方法,没有任何属性,并且全部是静态方法
BLL.Dept只有业务逻辑处理方法,没有任何属性,并且全部是静态方法
然后构造一个驱动
Controller.hDept 只调用Dept.aspx需要的各种方法,并且声明和实例化相关的类,
并且协调这些对象之间的处理
最后,UI层很简单
Dept.Aspx.cs 只需要实例化一个类Controller.hDept
如果需要替换UI,比如改为Winform的,也很容易以上抛砖引玉,我主要是想朋友们看看这样应用静态方法是否合适
我是觉得,那些类既然都不承载数据了,就可以用静态方法
可是这样一来,就不能用接口了,矛盾哦
最好哪位能指出这个构架的优点和缺点,
本菜秧好于CSDN诸位菜油和虾米共勉,
没什么好回报的,只有把分都给上

Answer 1

Controller.hDept 只调用Dept.aspx需要的各种方法,并且声明和实例化相关的类, 
－－－－－－－－－
前面的就三层机制，这句什么意思哦，不看懂

Answer 2

更正一下 ,BLL.Dept只有业务逻辑处理方法,没有任何属性,并且全部是动态方法

Answer 3

我详细的说一下我的项目构架:
1、通用层Common：通用业务逻辑和通用数据访问方法，静态，应用程序无关；2、实体模型层Model：映射数据库的字段、存储过程参数（当然，重复的不再声明），
   只有属性，需实例化；3、接口层：细分为两个命名空间：IDAL、IBLL4、数据访问层DAL：映射存储过程调用，静态方法，没有属性,不再关注实体细节
  （我们的数据操作都是由存储过程实现的，没有客户端Sql）；5、业务逻辑层BLL：实现业务逻辑算法，与数据访问无关，不会调用DAL的任何方法,
   同样没有属性,也不用关注实体的细节;6、驱动层Controller：按用户功能模块划分
   比如：基础信息类驱动、订单类驱动、代码生成类驱动，
   在这里会调用整合DAL、BLL、DAL中相关的对象；7、界面层Web/WinForm:每个界面只需要跟一个驱动打交道,这个调用场景几乎是
   被调用的驱动为它量身打造的,设计者无需关注不必要的细节了.
   将来替换界面层的工作量也大幅度下降
待续……
  

Answer 4

目前,Model层、DAL层的代码是通过自己写的代码生成器生成的

Answer 5

13楼我问你:有个查询返回这样的订单明细流水数据:
客户名,订单号,制单人，商品名称、商品编号,日期,数量,价格
查询条件是:客户名、制单人、订单号、商品名称、商品编号
这个方法算到那个实体里呢?
项目里有很多方法很难界定的，
在设计方法时我并不关心Model的细节，我只提供不依赖某个实体的服务
走后由控制器想需要的“消费者”提供他想要的服务