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