完成连接数据库修改删除添加等的实现细节,例如 语句是怎么写的,怎么把对象放
入数据库的。 层是面向功能的,一个个功能模块比如说银行登记并完成一次存款 ,
要把请求给 层,然后 曾将这一个 分解成许多步骤调用底层的实现完
成这次存款, 就是下面那层。
就是把数据存起来,之所以 的方法会有雷同只不过是因为 得需求不是很
复杂不用再 里面完成太多包装或者处理过程可以直接调用 的方法就完成的请求
处理例如就要 一个对象,而这个对象是封装好的, 里面有个方法专门 封装好
的对象于是 的方法就仅仅调用一下就 了,函数签名自然很像了 不能直接接
触持久层,而 是持久层或者直接访问持久层有的时候只是为了分层清楚,为了将来
的时候方便我们才把 和 分开,其实没必要分开的。
根据不同项目的复杂度来确定是否需要分层如果是小项目的话 层应该就够了分层是为了
很好的解耦和程序的可观性还有就是很好的项目分工如果遇到某个客户需要修改某个查
询结果集合你需要修改的首先是 的 接着是 的相应调用方法来为 服务
如果是分层清楚的话只需要在 中加一个方法在 中改变起调用的方法街口需
要改动的不大
在用 进行开发中,一般情况下都是分为三层 !" 层 #$ 层 层,基本的流程是首
先定义一个 接口,然后去实现这个接口,在定义同类型的 接口( 接口与
接口是完全一样),再实现 接口,(这是是用 接口去注入),然后 !" 层
在去调用 层。
层 的 职 责 是 纯 粹 的 数 据 操 作 , 如 果 是 "#% , 那 就 只 需 要 类 似
$%&"#%'(%)*+%%,#-.-/这类的方法而 层是负责写业务逻
辑的, 纯粹的业务逻辑, 其中的数据操作是通过注入的 实现的, 但是业务是在这层。
如果你的 层与 层代码严重重复,这说明你的业务比较简单。复杂业务这个结构
的优势就很明显了 层的作用是对 取得的数据做操作 更贴近于业务的实现 只
是数据的增删改查,对小型的应用来说,&确实提高了开发成本和开发周期,但是却有
利于扩展和维护。
利用 #$的 解偶 使业务逻辑与持久层松偶合。
分层并不一定是绝对的,具体的还是要根据项目实际情况来定,不是么?如果是理想状态
的话,恐怕在你的 层上面还要再多加一层的。但是你觉得有必要吗?
实际上,对于小项目来说,直接通过 来进行操作也不是不可以,搞得太复杂,也没有
必要。这是我的个人感觉。就好像 和 % 一样,有的人直接就将 传到 !" 层,有的
还要加一个转换,由 % 进行数据传递。显然后者实现更理想,但是你不觉得这样很麻烦
吗。
微软的。#% 号称有 00 层(还是多少层来着,反正层很多),但是实际能分出多少层,还
是根据开发者自己情况来定了。要注意代码是死的,人是活的,不要死套框架,否则自己
很可能也会陷入开发误区。
另外,我们目前设计的一些领域对象,绝大多数都是贫血的。只是一个简单的 1"#,
不包含任何逻辑在里面。怎么设计才更符合 的思想,你也可以参考下 (#"1% 方
面的讨论。这个在 1- 上有很多。