域模型对象在层之间传递是否有开销？
我正在开发一个使用 hibernate 和 spring 的项目。 Hibernate被封装在DAO层中，DAO层也有相应的服务层，还有映射请求和JSP页面的控制器。我被告知不要在这些层之间传递对象（控制器 <-> 服务 <-> DAO），因为这是性能开销。一个特殊的例子是，当我需要更新域对象（ORM 类）中的布尔值时，我编写了一种在 Service 层和 DAO 层之间传递域对象的方法，并被告知传递对象 ID 和特定的布尔值仅值并为此在层中编写单独的方法。这是对的吗？我觉得这样做会使使用 ORM 工具（Hibernate）的许多优点失效。我这样想有错吗？任何建议和见解都会有用......
I am working on a project that uses hibernate and spring. Hibernate is encapsulated in a DAO layer and the DAO layer has corresponding service layer as well, theres also the controllers that is mapped for requests and JSP pages. I was told not to pass objects between these layers (Controllers <-> Service <-> DAO) as it is performance overhead. One particular instance was when I needed to update a boolean value in a domain object (ORM class), I wrote a method that passed the domain object between Service layer and DAO layer, and I was told to pass the object ID and the particular boolean value only and to write separate methods in the layers for that. Is this right? I feel doing so will invalidate many advantages of using an ORM tool (Hibernate). Am I wrong to think this? Any advice and insights will be useful....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你是100%正确的。这是个糟糕的建议。传递物品。这正是 Hibernate 的设计目的，正常传递对象的“性能开销”简直是疯狂。除非该应用程序中有您不知道的内容，否则请警惕告诉您这些信息的人的建议。
You're 100% right. That's terrible advice. Pass the objects around. It's exactly what Hibernate is designed for, and "performance overhead" for normal passing of objects is just crazy. Unless there's something about the app that you don't know, be wary of advice from the person that told you that.
与大多数架构问题一样，这里需要进行权衡。
对于不希望使用面向服务的体系结构的应用程序（例如，具有支持数据库的独立网站、单个内部业务应用程序），最好在应用程序的所有层公开域模型。这可以确保您不会违反 DRY（不要重复自己）原则，并且每次向域模型添加新属性时都不必进行大量重构。您还可以使用 NHibernate Validator 之类的框架一次性定义所有验证，并将该验证用于数据层和 Web 层。
对于包含许多独立服务的大型应用程序（例如大型内部业务应用程序套件），最好将 ORM 与服务接口分开。这将允许您在不更改服务接口的情况下更改数据访问模型（反之亦然），当许多其他服务依赖于您的接口保持稳定时，这非常有价值。
但是，您描述的情况（使用方法来更改特定属性）似乎与这些场景都不匹配：遵循您描述的模式通常是一个坏主意，因为它使得跟踪执行路径和重构非常困难（并且可能会导致意大利面条式代码）。我能想到的唯一可能的用途是，如果您的数据模型非常大（5k XML blob 等），并且通过服务层发送它们会产生大量流量。 （注意：正确序列化时，C# 对象比 5k 小得多！）
我建议您将整个数据访问模型传递到 Web 层。
As with most architecture issues, there is a tradeoff to be made here.
For applications that don't expect to use a service-orientated architecture (e.g. a self-contained website with backing database, a single internal business application), it's much better to have your domain model exposed at all layers of the application. This ensures that you don't violate the DRY (Don't Repeat Yourself) principle, and you don't have to do lots of refactoring every time you add a new property to your domain model. You can also use a framework like the NHibernate Validator to define all of your validation once, and use that validation for both the data layer and the web layer.
For larger applications that contain many separate services (e.g. large suites of internal business applications), it's desirable to separate the ORM from the interface of the service. This will allow you to make changes to your data access models without changing the interface of the service (and vice versa), which is extremely valuable when many other services depend on your interface remaining stable.
However, the situation you describe (using methods to change specific properties) doesn't seem to match either of these scenarios: it's generally a bad idea to follow the pattern you've described as it makes tracing execution paths and refactoring very difficult (and can lead to spaghetti code). The only possible useage I can think of is if your data models are very large (5k XML blobs, etc) and sending them across the service layer would generate large amounts of traffic. (NB: C# objects are much smaller than 5k when serialised correctly!)
I would recommend that you do pass the entire data access model up to the web layer.
过早的优化是万恶之源
即使在 50 纳秒至关重要的高频交易中，您也会先做正确的事情，然后在需要时进行优化。您会对现代编译器/网络带宽的能力感到惊讶。
更直接地回答你的问题=>传递这些对象而不考虑性能。如果稍后需要的话，您会这样做，但是极不太可能是由传递对象引起的。
premature optimization is the root of all evil
Even in High Frequency Trading, where 50 nanoseconds matter, you do what is right first, and then you optimize if needed. You'd be surprised what modern compilers / network bandwidth can do.
To answer your question more directly => pass those Objects around and don't think about the performance. You will, if you need to later, but it is highly unlikely it is going to be caused by passing Objects around.