请问如果没有持久化层,还能否存在业务层

11-03-22 wqs918
              

我经常用到一般都是STRUTS+WEBSERVICE 或者是SSH框架,我总是感觉写来去就是为了和DB打交道,利用CURD组织成画面的数据,我完全感觉不到业务逻辑是在SERVICE层,SERVICE根本不像对象,更像是一个函数库,

对于WEB开发,业务逻辑明显是存在数据库里,而画面就是业务逻辑的直观体现,至少我现在感觉REST的开发模式更适合WEB开发,而所为的SERVICE层DAO层,有点脱裤子放屁的感觉,当然我初识DDD,我的想法一定是挺肤浅的,但对我来说确是真实的,所以,恳请道长指点迷津,先谢谢了

              

5
SpeedVan
2011-03-22 23:32

一个领域内存在许多实体,他们都在仓储里面待命中。当业务发生时,相关实体就会进入发生的业务场景进行交互。业务的完成会引起实体的诞生、消亡和状态的迁移。这当中没有DB概念,仓储就如一个实体集合,它已经把DB屏蔽了。当然了,好的仓储是关键了。

banq
2011-03-23 08:55

2011年03月22日 23:16 "wqs918"的内容
对于WEB开发,业务逻辑明显是存在数据库里,而画面就是业务逻辑的直观体现 ...

这是目前现状,用数据库来替代业务,业务都是扁平化静态化为数据保存在数据库中,而REST基本是数据的修改查询动作,所以,在这个架构中,REST其实充当持久层接口作用,这也是为什么很多持久层技术如NoSQL数据库使用REST作为其调用接口的原因。

因为我们普通都是用REST直接和界面显示挂钩,结合上面REST又是持久层的结构,那么我们的简单架构就变成:界面 + REST + 持久层。

这个架构就像当初MVC一样,简单易用,问题还是灵活性不够,业务都基本钝化成静态数据保存在数据库中,当业务复杂时,我们需要改变上面架构为:界面 + REST + 业务模型 + (REST)持久层。

前面的REST是直接和界面挂钩,后面REST是和持久层接口,所以,REST是一个接口作用在这样架构中非常明显。

另外根据DDD,业务逻辑也不是放在Service中,而是在领域模型如实体相关的模型中。

DDD是针对复杂系统应付变化的一套方法,如果你的系统不复杂,只是数据的CRUD,那么没有必要使用DDD。

你说的将业务逻辑放在Service中,是一种SOA做法,将数据整合作为功能对外提供服务,这种架构个人认为已经失败。

总之,现在有三种架构:REST架构基本可替代过去的SOA架构,这两个都和纯技术有关,把业务看成数据,所以,你基本都是和数据库打交道,这时数据库=业务层+持久层。

当,业务复杂以后,你就不能就技术论技术了,你就必须将业务层和持久层从数据库中解放出来,将计算和存储分离,这就是现在云计算架构。

SpeedVan
2011-03-23 09:57

若果建立模型时,则看到底把业务逻辑放在哪里,放在service则是service相当于context,放在模型则模型就是context(界限上下文)。个人感觉,DDD的模型=实体+逻辑,以内聚的方式实现。DDD不需要场景代码来支援,因为模型就是场景了。

“一个单词或一个句子所出现的环境,这个环境会反过来影响它们的含义。”这就是名可名,非常名了。模型是边界,就是环境,它决定了内部的所有含义,场景也是边界,也是环境,只不过场景决定的是role和im。而DDD的实体隐含了role了,所以DCI的D叫做DATA,只有成为role了才可以和DDD的实体等价。这样理解不对?

wqs918
2011-03-29 09:03

banq 老师的分析确实让我看清了为什么我现在写的代码是这种感觉的,可是真正DDD的业务真的就能放到数据库以外,我同意SpeedVan 兄的说法,仓储的设计最重要,因为按照DDD的步骤是先分析好聚合的实体,然后设计仓储,而仓储是什么,它就是关系数据库的封装,仅仅是把select变成get,把insert变成add,把delete变成remove,数据库又是ER图的物理实现,ER图恰恰的实体关系图,那我是不是可以认为DDD的目的就是为了画出一个ER图呢,那这各数据库驱动的开发方法,应该是一曲同工,并无优劣之分啊,我不知道我的分析对不对,请先辈赐教

2Go 1 2 下一页