以下的段落来自于POJO IN ACTION，作者显然基本是Exposed Domain Model pattern的支持者，但他的几个观点与我还是有不小的差异。原文没有翻译，我的Comment也用英文写出便于参照。
One drawback of using a POJO façade is that you must write potentially complex and error-prone code to detach domain objects.
(Of course we must do that because we are forced to repeat the model as a set of facades and a lots of DTOs)
A simpler approach, which eliminates the need to detach objects, is to use the Exposed Domain Model pattern. This pattern keeps the persistence framework connection open for the duration of the request, which allows the presentation tier to lazily load objects.
(This pattern does not necessarily keeps the framework connection open, just that the OpenSessionInView do it(Spring); Exposed Domain Model pattern as a methodlogy has no direct relationship with it; In fact we do have other alternatives.)
The presentation tier calls domain services to update the domain objects, as well as repositories to query the database, and then gets the data to display directly from domain entities and value objects. You no longer have to worry about detaching the objects that it needs. However, while this approach reduces the amount of code that you must write, there are some tricky design issues because of how transactions, persistence frameworks, and the servlet API interact. Also, the lack of a façade increases the chance that changes to the business tier could affect the presentation tier. There is also the risk of business logic creeping into the presentation tier. Despite these drawbacks, this approach makes sense for many applications and is becomingly increasingly popular.
(In my opinion the other side is more troublesome: the existence of facades tends to absorb logic that should belong to core model and eventually loads to lots of vertically divided structural elements which is most harmful to the health of the system.)