讨论：多层架构中是不是绝对不能把PO传递到表现层？

pufan，如果MVC叫做系统架构，倒的晕的不该是你，该是我了，我无话可说。你好好看看MVC 的书，好好理清楚它的来源吧。

（它最早出现于smalltalk，比较成熟地运用于java的swing，一直到后来b/s的广泛应用，才将这样的思维或者说模式移植到web应用中。smalltalk是架构么？swing是架构么？）

在 Pattern-Oriented Software Architecture, Volume 1，MVC是第125页，属于交互系统的体系结构模式之一

我估计不少人把体系结构等同于分层和如何分层了。

 
I very much agree with dirkschmidts point, I really think DTOs are an evil thing. Basically this is all the way back to the structs of the C age. I really think both view and application logic should operate on the same domain model. If you need to restrict client access somehow use interfaces, and let the view work on the interfaces only, or use delegation/subclassing.

IMHO if you can't do something.getXXX() anymore in a view/client, you are seriously fucked Of course this gets you some other problems like object graph partitioning, to not load the whole object graph. I think Hibernates lazy loading features do a great job here allready on the server side, but it gets really nasty if you have rich-client applications where lazy loading carries a potentially large overhead.

I kind of like the idea behind Entity Beans remoting, if that would not make them totally unusable because of network overhead.

So IMHO, you should really try to reduce additional layers as much as possible, keep one domain model and try to use this domain model from the view, too. There is much to much overengineering around, promoting things like DTOs/DAOs and all that stuff in the name of the magical "decoupling", which will not be of use in most cases anyways. I allways try to stick with the YAGNI principle.

Just my two cents

 
A couple of thoughts. I have been giving this a lot of thought over the past 3 months for a proposal I am making to my bosses regarding a change in our application architecture. We currently have this pretty typically service layer setup where the service layer mediates between the UI and the domain model using DTOs as the exchange mechanism.

Are DTOs evil? I kind of go back and forth on this. In gerneral, no I don't think DTOs are evil. I think the amount of my time they waste is evil, but that is where something like CarrierWave comes into play by helping to manage not only the generation of the DTOs, but also the marshalling between DTO and domain entity.

I think it really comes down to the type of application architecture and topology you use. In a fully-colocated servlet-based or fat-client stack, DTOs probably don't make that much sense. Just open the Hibernate session and manipulate your entities at will. But what if you need to split that servlet-based stack into vertical partitioning for network security or clustering reasons? Now how do I manage this? I can't simply "Open Session in View" anymore... So I use Hibernate's disconnected object support.

But consider a product built using Hibernate that exposes an API in this fashion, that you as a developer need to interact with. So you retreive an object and then attempt to access one of it's properties (which happens to be lazy loaded). Boom, lazy init exception. "But the API says that object has that property..." Yes, I know, you could just simply initialize that lazy property prior to sending it outside of the persistence-context; but where does it stop? How deep should I init? Disconnected object support is great in all kinds of scenarios, but it certainly isn't a catch all.

I just don't think there is a hard-and-fast rule here that says you should never be using DTOs; and especially on the argument that they're not true object because they only represent data. Pure data representations are uber-useful for all kinds of things. To me, you're fooling yourself if you think you need a domain entity with all its domain logic intact to populate an html <select> list (if your using JSF or Tapestry or WebOGNL, then thats a different story).

难得老皇同志你抽空写这么多文字去辩论MVC是架构还是模式。

多层架构有那么神秘吗？其本质无非就是MVC。

结果老皇同志非要论证MVC是架构还是模式，真是让人哭笑不得。