我正在开发一个使用hibernate和spring的项目。 Hibernate封装在DAO层中，DAO层也有相应的服务层，还有为请求和JSP页面映射的控制器。我被告知不要在这些层之间传递对象（控制器＆lt; - ＆gt; Service＆lt; - ＆gt; DAO），因为它是性能开销。一个特殊的例子是当我需要更新域对象（ORM类）中的布尔值时，我编写了一个在Service层和DAO层之间传递域对象的方法，并且我被告知要传递对象ID和特定的布尔值仅限值并在图层中为其编写单独的方法。这是正确的吗？我觉得这样做会使使用ORM工具（Hibernate）的许多优点无效。我觉得这个错了吗？任何建议和见解都会有用......
答案 0 :(得分：6)
你是100％正确的。这是一个糟糕的建议。传递物体。这正是Hibernate的设计目标，而正常传递对象的“性能开销”实在是太疯狂了。除非您不知道该应用程序的某些内容，否则请小心那些告诉您的人的建议。
答案 1 :(得分：3)
与大多数架构问题一样，这里需要进行权衡。
对于不希望使用面向服务的体系结构的应用程序（例如，具有后备数据库的自包含网站，单个内部业务应用程序），最好在应用程序的所有层上公开您的域模型。这可以确保您不会违反DRY（不要重复自己）原则，并且每次向域模型添加新属性时都不必进行大量重构。您还可以使用NHibernate Validator之类的框架来定义所有验证一次，并对数据层和Web层使用该验证。
对于包含许多单独服务的较大应用程序（例如，大型内部业务应用程序套件），需要将ORM与服务接口分开。这将允许您在不更改服务接口的情况下对数据访问模型进行更改（反之亦然），这在许多其他服务依赖于您的接口保持稳定时非常有价值。
但是，您描述的情况（使用更改特定属性的方法）似乎与这些场景中的任何一个都不匹配：遵循您描述的模式通常是一个坏主意，因为它会跟踪执行路径和重构非常重要困难（并可能导致意大利面条代码）。我能想到的唯一可能的用途是，如果您的数据模型非常大（5k XML blob等），并且通过服务层发送它们会产生大量流量。 （注意：正确序列化时，C＃对象远小于5k！）
我建议您将整个数据访问模型传递到Web层。
答案 2 :(得分：3)
过早优化是万恶之源
即使在50纳秒重要的高频交易中，您也会先做正确的事情，然后然后根据需要进行优化。你会对现代编译器/网络带宽能做什么感到惊讶。
更直接地回答您的问题=＆gt;传递这些对象，不考虑性能。如果你以后需要，你会发现高度不太可能是因为传递对象造成的。