DAO数据访问模式

ORM已经不好了，ActiveRecord其实比ORM更坏，因为它隐藏对象其实是数据容器这样的事实，如果说ORM是将真正对象变成数据容器，那么ActiveRecord还隐瞒了这样事实，也就是说，如果说ORM做了偷梁换柱的坏事，ActiveRecord不但做了，还隐瞒自己做的坏事。

需求描述是这样的：crm系统中。“潜在客户”归档后变为“客户”。这个“归档”需要创建一个“客户”，并删除对应的“潜在客户”。新的“客户”对象的属性值多数是来源于原来的“潜在客户对象”。 这个Archive是一个业务方法，那么它应该写在domain层

Repository模式又称为仓储模式或存储库模式，替代以前的DAO模式: 存储库模式限制我们在应用程序直接使用数据库的数据，并为数据库操作，业务逻辑和应用程序的UI创建新层。 它是软件设计

如果要删除指定标识的实体，是由Respository来操作，还是Entity本身来操作？ 从业务角度来看，入库、出库都需要记录，删除操作自然应该放在Respository。可是Respository并不知道Entity的细节，如何执行删除操作？ <

这是来自Node.js路线有关混合两种ORM模式Active Record（活动记录模式）和Data Mapper（数据映射模式）的思考。其实质是引发了失血模型与充血模型的区别，更深层次是引出了掌握DDD的必要性。 首先这两种持久模式的特点如下：A

很久没有写过hibernate的代码，现在回头想重新看一下但是却有了很多新的思考，最重要的一个就是DAO对象与hibernate提供的session，在没有ORM框架的时候我们只能使用JDBC，对于数据库的访问需要很多步骤，其中主要的是对模型对象与数据表映射的工作，所以存在了DAO，但是现在有了

存储库和DAO的实现被认为是可互换的，尤其是在以数据为中心的应用程序中。这引起了他们之间差异的困惑。在本文中，我们将讨论DAO和存储库模式之间的区别。 DAO模式数据访问对象模式（也称为

数据传输对象DTO是在进程之间承载数据的对象。使用它的动机是进程之间的通信通常通过远程接口完成，其中每次调用都是昂贵的操作。由于每次调用的大部分成本都与客户端和服务器之间的往返时间有关，因此减少调用次数的一种方法是使用一个对象（DTO）来聚合本应传输的数据由几个调用，但仅由一个调用提供服务。

如果domain不能访问dao，来获取数据，那么很多业务方法无法实现啊。这时在将业务方法移动到service层，那不是很失败？ 如果domain需要访问数据，那岂不是依赖dao层了？

请问，项目使用 DDD 方式开发的话，开发顺序是否先是 Domain Model, 然后才是 Repository, 然后调用 Dao 或者不用 Dao 也行，将对象持久化，然后再设计数据库？因为受传统观念影响，我一直是认为项目开发应该是先开发数据库的。因为这个观点，我看了两天这方面的资料，

设计模式是软件开发过程中经常出现的问题的常见解决方案。这些解决方案提供了优雅且在大多数情况下解决与对象创建，资源分配，简化代码等相关的不同问题的最有效方法。需要维护它们的上下文，而解决方案本身需要定制，根据业务逻辑。 设计模式分为三类： <

最近产生了一个争论问题，有的人说在Spring+mybatis运用中坚持要这样写：

如图，订单状态有New Order，Registered，Granted，Shipped，Invoiced，Cancelled，相当复杂，在不同的状态执行操作时会产生不同的影响，比如说我们要执行AddOrderLine的话，要判断订单状态，如果是Registered或Granted状态的话，

在JAVA EE中，我们设计DAO的时候，发现所有的项目都是写成接口形式，然后使用具体的DAO对象去实现这个接口，如：public interface GenericDao { public List findByID(Long id);}class Us

如果对于GenericUnregMenuDAO类事例化的问题，请高手指点，分别放在以下代码不同3个位置，请问，哪个位置声明比较合适？ package com.chinarainbow.otas.kernal.queue.OTAHandlers; <

技术框架： spring+ibatis 比如我有个文章详情页，页面右侧会显示“最火的10篇文章”，那么这10篇文章是从service里取还是从dao里取？我的习惯是直接从dao里取，service层留给业务概念里的“服务”。可是吧。。。如果是给传统企业做信息化，业务概念里倒是可能会