I found JPA, or alike, don't encourage DAO pattern. I don't know, but I feel like that, especially with server managed JTA managers.
After adequate hands-on using DAO pattern, I started designing JPA based application around that pattern. But it doesn't fit in, IMO. I tend to lose quite a features of JPA and all.
Well, suppose you fire a query with pessimistic locking and it returned a list of entites from a DAO method. Upon returning, transaction ends and lock is gone (a case with server managed JTA manager). So, no point, loosely speaking. There are valid cases, though.
Another example is much more trivial. Suppose you fire a query to get some entity, that has a lazy loading one-to-many association with some other entity. Upon returning the DAO method, transaction ends. Lazy loading wouldn't work anymore, you simply get `null` or something. To cope with that we load it eagerly manually. we do something like `a.getBList().size()`.
Thus, IMO its better to not make a DAO exclusively, and do it in your business bean, this way you will be able to take advantage of those useful features. Or ORM API can be considered a DAO/Data-layer itself, arguably. So, we don't need to make another.
What you folks think about it?
**Note: I don't say, by any means, that the DAO pattern is obsolete. Indeed it depends case to case.**
以上就是I found JPA, or alike, don't encourage DAO pattern的详细内容，更多请关注web前端其它相关文章！