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

[缪军]

我的项目是这样一种模式(通用层就不说了)
首先,我把属性和方法彻底分离到不同的类中:
Model.DeptInfo 只有属性,并且没有静态成员,需实例化调用
DAL.DeptDA 只有数据访问方法,没有任何属性,并且全部是静态方法
BLL.Dept只有业务逻辑处理方法,没有任何属性,并且全部是静态方法
然后构造一个驱动
Controller.hDept 只调用Dept.aspx需要的各种方法,并且声明和实例化相关的类,
并且协调这些对象之间的处理
最后,UI层很简单
Dept.Aspx.cs 只需要实例化一个类Controller.hDept
如果需要替换UI,比如改为Winform的,也很容易

以上抛砖引玉,我主要是想朋友们看看这样应用静态方法是否合适
我是觉得,那些类既然都不承载数据了,就可以用静态方法
可是这样一来,就不能用接口了,矛盾哦
最好哪位能指出这个构架的优点和缺点,
本菜秧好于CSDN诸位菜油和虾米共勉,
没什么好回报的,只有把分都给上

[fengxuanll]

做个标记学习学习``

[MicroDeviser]

顶

[ttg520]

mark

[anncesky]

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

[amanizty]

up~

[effun]

属性和方法没有深仇大恨的，不需要这样绝对地分开来，在逻辑层中有适当的属性会让程序更容易开发和理解。

[wsj1983920]

up

[hangang7403]

把属性与方法完全分开，有背于面向对象编程中对象的概念

[江城老温]

没必要为了分层而分层。练手的话，可以理解。做项目，就别这么整了。一切为了方便。

[缪军]

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

[缪军]

我详细的说一下我的项目构架:
1、通用层Common：通用业务逻辑和通用数据访问方法，静态，应用程序无关；

2、实体模型层Model：映射数据库的字段、存储过程参数（当然，重复的不再声明），
只有属性，需实例化；

3、接口层：细分为两个命名空间：IDAL、IBLL

4、数据访问层DAL：映射存储过程调用，静态方法，没有属性,不再关注实体细节
（我们的数据操作都是由存储过程实现的，没有客户端Sql）；

5、业务逻辑层BLL：实现业务逻辑算法，与数据访问无关，不会调用DAL的任何方法,
同样没有属性,也不用关注实体的细节;

6、驱动层Controller：按用户功能模块划分
比如：基础信息类驱动、订单类驱动、代码生成类驱动，
在这里会调用整合DAL、BLL、DAL中相关的对象；

7、界面层Web/WinForm:每个界面只需要跟一个驱动打交道,这个调用场景几乎是
被调用的驱动为它量身打造的,设计者无需关注不必要的细节了.
将来替换界面层的工作量也大幅度下降
待续……

[缪军]

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

[lxl_sports]

实体层
包括 属性和方法。。。

所以不建议分开

[缪军]

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