虚拟与接口 poco，哪个更快？
我正在维护一个设计如下的应用程序：
messy code --abuses--> simplePoco (POCO data capsule)
数据胶囊是一个简单的类，有很多 getter 和 setter（属性）它使用 DI 框架并一致使用 IoC 容器来提供数据胶囊的实例（幸运的是我！ ）。
问题是，我需要在 simplePoco 中引入“更改通知”机制，
messy code --abuses--> simplePoco
|
V
changes logger,
status monitor
(I wanna know about changes)
我有几个选择：
引入一个
IPoco并修改凌乱的代码，这样我可以使用simplePoco来提高速度，还是使用notifyingPoco当我想要更改通知时（选择性地慢）？或者...使所有内容虚拟并在
simplePoco之上滚动我自己的自定义notifyingPoco类（甚至更慢）？我不知道的设计模式？
这是一个客户端/服务器系统，但我只是修改服务器部分，所以如果可能的话，我宁愿不接触混乱的代码或客户端代码（有序列化器和反射以及可怕的忍者东西） ...）以免意外损坏任何东西。
使用接口会阻止 JIT 内联对 getter/setter 的调用吗？
考虑到 simplePoco 实例被严重滥用，最好的方法是什么？
I am maintaining an application which has been designed like this:
messy code --abuses--> simplePoco (POCO data capsule)
The data capsule is a simple class with lots of getters and setters (properties) It uses a DI framework and consistently use the IoC container to provide instances of the data capsule (lucky me!).
The problem is, I need to introduce a "change notification" mechanism into simplePoco
messy code --abuses--> simplePoco
|
V
changes logger,
status monitor
(I wanna know about changes)
I have a few options:
Introduce an
IPocoand modify the messy code, so that I can havesimplePocofor the speed ornotifyingPocowhen I want change notification (selectively slow)? or ...Make everything virtual and roll my own custom
notifyingPococlass on top ofsimplePoco(even slower)?design patterns that I do not know?
It is a client/server system but I'm just modifying the server part so if possible, I'd rather not touch the messy code or the client code (there are serializers and reflections and scary ninja stuffs...) as to not accidentally break anything.
Would using an interface prevents JIT from inlining the calls to getter/setter?
What's the best way to go considering that simplePoco instances are heavily abused?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
任何类型的虚拟调用（无论是在接口上还是直接在类上 - 所有接口调用都是虚拟的！）将不会被 CLR JIT 内联。也就是说，接口调用稍微慢一些，因为它们必须始终通过潜在的远程/代理路径，并且因为它们必须在进入主体之前将
this指针移动到指向类的开头的函数。直接对类成员进行虚拟调用永远不必进行转换，并且除非该类派生自 MarshalByRefObject，否则不会进行代理检查。也就是说，这两者之间的性能差异非常小，因此您可能应该忽略它们并专注于设计的简洁性和易于实现。
Any kind of virtual call (whether on interface or directly on a class - all interface calls are virtual!) will not be inlined by CLR JIT. That said, interface calls are slightly slower because they must always go through the potentially-remoted/proxied path, and because they have to shift
this-pointer to point at the beginning of the class before entering the body of the function. Virtual calls directly on class members never have to do the shift, and, unless the class is derived fromMarshalByRefObject, do not hit the proxying checks.That said, performance differences between these two are very minor, so you should probably ignore them and focus on cleanliness of design and ease of implementation instead.