.Net 远程处理而不使用 .Net 远程处理？
我最需要的是一些建议。
我有以下示例：
Appication1.exe - 有对象 MyList
Application2.exe - 需要访问 MyList 并与该对象交互，就像它是从 Application2 创建的一样。
我应该使用 .NET Remoting（即 2.0）还是 WCF 或其他技术堆栈？ 有哪些框架可以支持这一点？ 各自的优点/缺点是什么？
我应该指出，这更像是一个“帮助”应用程序，开发团队之外的任何人都不会使用。
I am after some advice more than anything.
I have the following example:
Appication1.exe
- Has object MyList
Application2.exe
- Needs to gain access to MyList and interact with the object as if it was created from Application2.
Should I be using .NET Remoting (ie 2.0) or WCF or another technology stack? What frameworks are available to support this? What are the advantages / disadvantages to each?
I should note, that this is more of a 'helper' application and won't be used by anyone outside of the development team.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果不了解有关您的应用程序的更多详细信息，很难说，但就我个人而言，我不会在这种情况下使用 WCF。 WCF 具有非常重量级的管道，需要花费大量精力来设置和使用。 它的 API 也主要面向 Web 服务，这在您的情况下似乎有点过分了。 Microsoft 声称 WCF 取代了远程处理，因为他们不想再支持远程处理，但是在使用了这两种方法之后，我可以说 WCF 不如远程处理在同类应用程序内移动数据。
然而，将数据从一个应用程序移动到另一个应用程序的方法有很多种，每种方法都有各自的优点和缺点。 对所有这些方法的全面讨论超出了本评论的范围。 您能否添加有关您的使用场景的更多详细信息？ 这个列表中有什么样的数据，有多大，从哪里来，正在进行什么样的修改，应用程序 1 是否需要查看更改，应用程序 2 是否会将数据发送到其他地方完成，等等...
Its hard to say without knowing more details about your applications, but personally I would NOT use WCF for this scenario. WCF has a very heavy-weight pipeline and takes considerable effort to setup and use. Its API is also heavily geared toward web services, which would seem to be overkill in your case. Microsoft claims that WCF replaces remoting because they don't want to support remoting anymore, but having used both, I can say that WCF is not as good as remoting for moving data around inside homogeneous applications.
However, there are dozens of ways to move data from one application to another, all with their own pros and cons. A full discussion of all of these methods is beyond the scope of this comment. Can you add more detail about your usage scenario? What kind of data is in this list, how big is it, where did it come from, what kind of modifications are being made, does App 1 need to see the changes, is App 2 going to send the data somewhere else when it is done, etc...
我假设应用程序 1 是生产应用程序，应用程序 2 是仅供开发的帮助程序应用程序。 如果是这种情况，您的目标应该是最小化或消除应用程序 1 中与支持应用程序 2 相关的任何额外开销。因此，非常重的 WCF 应该作为一个选项被消除。 远程处理也会增加开销。
您可以序列化该对象 - 也许 XML 适合于此？
这个问题有太多变数，无法完整回答。 您能否提供有关应用 1 和应用 2 的更多信息？ 他们跑到哪里去？ 您感兴趣的对象经常变化吗？ 他们如何保存状态？
I'm assuming Application 1 is a production app, and Application 2 is the development-only helper app. If this is the case, your goal should be to minimize or eliminate any additional overhead in Application 1 related to supporting Application 2. So WCF, which is very heavy, should be eliminated as an option. Remoting also adds overhead.
You could serialize the object - maybe XML would be appropriate for this?
There are too many variables to this question to answer it completely. Can you provide more information on Application 1 and Application 2? Where do they run? Do the objects you are interested in change often? How do they preserve state?
很难说。 WCF 当然是一种可能性。 当然，您必须控制这两个应用程序，并更改 App1 以支持（无论是推式还是拉式模型）到 App2 的数据传输。 如果您不一定需要按需交换数据，则可以考虑将数据库作为传输数据的方法。 如果 App1 已经将一些数据写入数据库。 然后你可以让App2从那里获取它需要的数据。 或者，如果交换不经常发生，您甚至可以使用文件系统。 序列化列表并使用 App2 抓取它。 （我只是建议这样做，因为听起来您正在尝试将开发工具连接到已经存在的东西中）。
远程处理是一项较旧的技术，充满了困难的实施和部署问题。 WCF 更加简洁并且更容易实现。 因此，如果介于两者之间，我肯定会推荐 WCF 而不是远程处理。
It's hard to say. WCF is certainly a possibility. You have to have control of both apps of course and change App1 to support (either on a push or pull model) the data transfer to App2. If you don't necessarily need an on demand exchange of data, you could consider a database as the method of transferring data esp. if App1 already writes some data to a database. Then you can have App2 go grab the data it needs from there. Or you could even use the file system, if the exchange does not happen to often. Serialize out the list and grab it with App2. (I only suggest that because it sounds like you're trying to hook a dev tool into something that's already existing).
Remoting is an older technology that is fraught with difficult implementation and deployment issues. WCF is much cleaner and easier to implement. So, if it's between the two, I would definitely recommend WCF over remoting.
我认为合理的选择是使用 .NET 远程处理。 您必须在 Application1 上启动一个 Web 服务，以便 Application2 与之通信。 唯一真正的缺点是“MyList”需要用 MarshalByRefObject 进行标记。 MSDN 表示，Remoting 现在已成为传统的东西（.NET 3.0），有利于 WCF。 但据我所知，远程处理是镇上唯一用于跨应用程序域通信的游戏。
I think the resonable choice is to use .NET remoting. You would have to spin up a web service on Application1 for Application2 to talk to. The only real disadvantage is that "MyList" needs to be marked with MarshalByRefObject. MSDN says Remoting is now legecy stuff (.NET 3.0) in favor of WCF. But as far as I know, Remoting is the only game in town for cross-appdomin communication.