两个 wcf 服务器与带回调的 wcf 服务器
我有两个需要通过 WCF 进行通信的应用程序： 称为A和B。 A 假设将值推送到 B 进行存储/更新 B 假设将其中存储的值列表推送到 A，
我团队中的高级程序员想要在 A 处打开一个 WCF 服务器，在 B 处打开另一个 WCF 服务器。
我声称一个应该是服务器，另一个应该是客户端，使用服务器回调以避免将接口一分为二，避免循环依赖，以及重复的代码设置。他不明白。谁能帮我解释一下为什么他的解决方案是糟糕的代码？
I have got two applications that need to communicate via WCF:
Called A and B.
A suppose to push values to B for storage/update
B suppose to push a list of values stored in it to A
the senior programmer in my team wants to open a WCF server at A and another WCF server at B.
I claim that one should be the server and the other should be the client and use server call back In order to avoid splitting the interface into two, avoid circular dependency, and duplication of code settings. he doesn't understand it. can anyone help me explain him why his solution is bad code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于您的标准。让我们假设一个客户端/服务器模型，其中 A 是客户端，B 是服务器。您声明 B 应该将数据“推送”到 A。
如果您确实需要推送，那么您应该将 B 设为双工服务器。这确实会给您的带宽带来一些压力，因此如果您有带宽限制，这可能不是正确的选择。
如果您可能会在 A 处产生一些延迟，那么您可能需要选择自己的轮询机制（可能基于时间或其他一些逻辑）。
如果两者都不可行，您可以尝试交换角色。那么然后让B作为客户端，A作为服务器。它不太直观，但可能适合您的场景。如果存储数据可能会出现延迟，请让 B 轮询 A 以了解数据更改并按一定时间间隔保存。
如果两者都没有延迟并且带宽有限，那么您最终会得到两个 WCF 服务。尽管乍一看可能看起来很愚蠢，但请记住它们是服务而不是服务器。它确实让事情变得更加复杂，所以我会把它作为最后的手段。
It depends on your criteria. Let's assume a client/server model where A is the client and B is the server. You state that B should "push" data to A.
If you truly need push then you should make B into a duplex server. This does put some strain on your bandwith, so if you have a bandwith restriction, this might not be the right choice.
If you can incur some delay at A than you might want to opt for a polling mechanism of your own (maybe based on timing, or some other logic).
If both are not an option, you can try and swap roles. So then make B the client and A the server. It's les intuitive, but it might fit your scenario. If you can incur a delay on storing data, make B poll A for changes in the data and save at an interval.
If there can be no delay in both and bandwith is limited, you do end up with two WCF services. Altough it may look silly at first glance, keep in mind they are services and not servers. It does make things a bit more complex, so I would keep it as a last resort.
服务应该封装其他应用程序可以使用的一组功能。它所做的只是等待并响应来自其他组件的请求，它本身不会发起操作。
如果应用程序 B 正在存储数据，那么当然可以将其作为服务提供给应用程序 A。它提供了存储数据的“服务”，而应用程序A不必担心如何或在哪里存储数据，并返回成功存储的数据。这正是 WCF 服务要处理的事情。
我假设应用程序 A 是发起请求的应用程序（除非您有未提及的第三个应用程序，否则其中一个必须是发起者）。如果应用程序 A 正在启动操作（例如，它有一个 UI，或者被触发执行一些批处理等），那么它不应该被建模为“服务”。
我希望这有帮助:)
A service should encapsulate a set of functionality that other applications can consume. All it does is wait for and respond to requests from other components, it doesn't initiate actions by itself.
If Application B is storing data, then it can of course be provided to Application A as a service. It provides the "service" of storing data without application A having to worry about how or where, and returns successfully stored data. This is exactly the kind of thing that WCF Services are meant to handle.
I am assuming that application A is the one initiating the requests (unless you have an unmentioned 3rd application, one of them must be the initiator). If Application A is initiating actions (for example, it has a UI, or is triggered to do some batch processing etc.) then it should not be modeled as a "service".
I hope that helps :)