给大家一个新思想

这思想要抛弃很多东西,准备洗脑吧:

数据库 = 一个集合

我们过去总是在做这样的一件事,当我逻辑中需要什么时,就向DAO获取内容,这就是我们一贯的service调用dao的做法。我不批判这样的做法,但我自从走向函数式后,越来越感到原来做法的无力感,为啥service难于重用?因为dao内嵌在service中,使得service属于有态对象,当我们想重用时,却又不得不考虑dao具体是什么,什么状态下返回什么值。service怎么样才能成为纯正的逻辑体呢?


解放思想:数据库就是一个集合,当一个数据库支持某种语言时,必须实现语言中的集合是直接指向数据库核心,注意!这不是查询!!!具体的说法就是,Iterator的next和hasNext直接调用数据库的函数。当与数据库连接起来后,那就得到了一个集合Iterator,而所谓的查询就是筛选。用JAVA语言我们可以这么理解new Iterator(database)。数据库就是一个集合,查询后得到的数据集也是一个集合,这就是面向集合,mongodb就是这样的思想。

与过去不同,过去利用hibernate是直接得到指定的对象集,例如返回的List<User>等,但key value性质的数据库不是这样思考的,它返回的是通用概念的记录集(在mongodb中就是Iterator[DBObject],我用的是scala),这个记录集很不同,他其实是一个指针概念,他next和hasNext都是在遍历数据库这一集合本身(就像以前ASP返回的数据集意义一样),想转换成我们想要的对象,则通过隐式转换即可。


我们不是从数据库中得到集合,而是数据库就是集合本身。


鉴于此,对于开头的问题就有了解答:不是把dao(或者说迭代器等)内聚到service,或者注入。而是作为参数,作为一个集合传给service!And now,service就是我们想要的纯正的逻辑体。

(这是最近的思考,不一定能够全面地覆盖这一领域的知识,若有更深的思考,欢迎来交流)
[该贴被SpeedVan于2012-03-03 17:27修改过]
[该贴被SpeedVan于2012-03-03 17:28修改过]

同意lz的观点,这样可以降低耦合度,service变得更为抽象
可以根据传入不同的DAO,来实现不同的逻辑,这样service更像是一个大的框架