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