Rapae 弱化DAO的一种方法

你的图很漂亮，我明白的你的意思，或许他也有用武之地，另外那个地方不会出现线程不安全的操作，因为没有共享数据，完全针对一些不可变类的操作，没有对象状态的变化，就是根据interface的annotation，生成一个代理而已。

 哦，是的，我又回去仔细看了，的确没操作到共享数据，我道歉...

这个东西最好拿到项目中去试一下。

这样你就会发现，当你的Service层和Dao层合并以后，会造成你的业务逻辑层代码有多臃肿。我一直很困惑，如果一个业务逻辑方法中要包含5，6次的复杂数据库操作，你如果不搞个Dao，你的Service层代码很可能会瞬间超过1000行。

另外，一般的业务逻辑层之所以能够成为一个层次，是因为其需要完成的功能是过程式的，是复杂的。所以我很难奢望在一个真正的企业应用中，一个register方法会如此简单。难道仅仅是保存一把数据库就好了？

你搞一堆代码,我看的晕晕的,无非就是根据annotation去代替一些东西,为什么可以代替,因为你预先写了一些东西,请问还有更高招不?你完全可以直接在xml中写上一些配置,自动生成程序阿

所以我说我还是喜欢C多一些,搞java都被忽悠来忽悠去,搞的花样百出,但是没有实质的改变

这些东西弄来弄去，都一样。
我更关心的是:你的事务管理有没有问题?你的权限管理是否严谨?你的业务逻辑有没有问题?

首先我想说的是，我支持downpour对我的Service+DAO进行整合的观点的批驳。我在将自己的方法应用到实战的时候也的确遇到过一些非常严重的问题。

 

按照原来的Service+DAO架构，我们的确是需要DAO来封装我们的数据操作。DAO中也是不允许涉及到具体的业务逻辑的吧，所以5，6次复杂的数据库操作仍然得调用5、6次封装了复杂数据库操作的DAO来执行。但是DAO不涉及到业务逻辑的操作，所以我所遇到的DAO的每个单次操作都相对比较简单，都是类似于从数据库中增删改查等操作。

如附件的图1所示所示：为了降低Service层之间的耦合，一般我们都不让Service相互访问，都是使用对应的DAO层来进行访问。这样的好处自然是一块业务逻辑改变了，也不会影响到其他的业务模块。

 

这样将会产生一些比较无语的代码：

	public Result<Customer> findCustomer(Customer customer, Page page) {

		Map<String, Object> map = new HashMap<String, Object>();
		map = BeanUtils.pojo2Map(customer);
		return customerDao.pageCountByArgs(map, page);
	}

 

	public Customer getCustomer(Long customerId) {

		return customerDao.read(customerId);
	}

 这些代码无非都是简单调用DAO层，仅此而已，而且到处都充斥这这样的代码。如果一旦需要新增或者改动将会涉及到好几个文件的修改（如果DAO层封装够好的话，也需要修改IService、ServiceImpl与DaoImpl），findCustomer方法的作用仅仅是为了暴露出customerDao的pageCountByArgs方法而已。

 

如图2所示。Service层不再相互独立，相互的调用使得整个Service层紧密的耦合在了一起。我不得不承认修改一处业务逻辑的方法非常很有可能会导致其他业务模块的改变。但是这样的确加快了我的开发效率。

 

写到这里，我的GF又飞来一句冷刀直插我狡辩的心脏：

 哎...算了吧，帖子到此为止了。

所以目前我的想法是，让Service具备Dao的基本功能。

也就是说，Service的接口继承一个AbstractService接口，Service的实现继承AbstractServiceImpl的实现。在这个实现类中，你可以封装简单的数据库操作逻辑。这样你的Service中可以不需要为了“根据主键查询对象”这种简单的需求而再去额外定义一个接口函数。

不过这实在是有点不雅观。一个Service层的代码，原本应该是业务逻辑的核心，他对于容器、外部环境的依赖应该降到最低。但是突然你发现，一旦按照上面这种方法来，代码是简单了，但是所有能依赖的东西你全依赖上了。

在这个问题上，Java我觉得很无奈。

让我企图再度挣扎一下：

 

Service与Service之间的交流就好像人与人之间的交流一样，是相互协作的关系。当一个业务逻辑改变，相应的，和他有关的业务逻辑都将会受到改变。

 

举个简单的例子：

如 某个应用原来允许所有用户进行操作A，然后通过操作x才能到操作y。此时涉及到两个Service：ServiceA与ServiceB。B的y方法依赖于A的x方法。

 

若此时业务逻辑发生更改，要求只有在白名单的用户方能操作A.X。

 

如果根据传统的Service与DAO模型，我们必须要同时在A.x与B.y中判断用户是否属于白名单，少一个都将会发生事故。因为我们不知道那个WebController没经过A就直接调用了B.y（当然，实际上通过IDE就可以很快查出，不过至少你得为这个进行操心）

 

若是B.y完全依赖于A.x，那么我们只要在A.x中进行一次判断就可以解决问题 -- 当A的业务逻辑发生改变，相应的，和A有关的业务逻辑都将会受到改变

再改改就接近linq了