相关疑难解决方法(0)

我发现JPA,或类似的,不鼓励DAO模式.我不知道,但我觉得这样,尤其是服务器管理的JTA经理.

在使用DAO模式进行了充分的实践之后,我开始围绕该模式设计基于JPA的应用程序.但它不适合,IMO.我倾向于失去JPA和所有的功能.

好吧,假设您使用悲观锁定触发查询,并从DAO方法返回了一个entites列表.返回后,事务结束并且锁定消失(服务器管理的JTA管理器的情况).所以,没有意义,松散地说.但是有一些有效的案例.

另一个例子更为微不足道.假设您触发查询以获取某个实体,该实体具有延迟加载与其他实体的一对多关联.返回DAO方法后,事务结束.延迟加载将不再起作用,你只是得到null或什么.为了应对这种情况,我们热切地手动加载它.我们做的事情就像a.getBList().size().

因此,IMO最好不要专门制作DAO,并且在您的业务bean中执行此操作,这样您就可以利用这些有用的功能.或者可以说ORM API可以被认为是DAO /数据层本身.所以,我们不需要另一个.

你们有什么想法呢？

注意:我没有说,DAO模式已经过时了.实际上,这取决于具体情况.

我使用领域驱动n层应用程序体系结构与EF code first我在最近的项目中,我定义我的Repository合同,在Domain层.制定其他Repositories不那么冗长的基本合同:

public interface IRepository<TEntity, in TKey> where TEntity : class
{
   TEntity GetById(TKey id);
   void Create(TEntity entity);
   void Update(TEntity entity);
   void Delete(TEntity entity);
}

并且Repositories每个都是专门的Aggregation root,例如:

public interface IOrderRepository : IRepository<Order, int>
{
    IEnumerable<Order> FindAllOrders();
    IEnumerable<Order> Find(string text);
    //other methods that return Order aggregation root
}

如您所见,所有这些方法都依赖于Domain entities.但在某些情况下,应用程序UI需要一些不是Entity数据的数据,这些数据可能来自两个或更多的肠炎数据View-Model,在这些情况下,我定义了View-Models in Application layer,因为它们非常依赖于Application's需求而不是到了 …