单例引用

发布于 2024-08-18 06:22:31 字数 362 浏览 5 评论 0原文

好吧...我遇到的情况是 C# .dll 是单例。现在,我希望能够做的是,当实例化 singletonInstance 时,能够提供对可能启动的任何其他应用程序的引用。因此,我查找了 NamedPipes,这可以工作 - 除了一件事之外,这必须是跨平台的,或者平台独立的。我心里有一个解决方案,但我很难弄清楚是否可以通过句柄或其他方法派生对 singletonInstance 的引用?

既然已经有了一些评论和问题,我可以多解释一点并澄清:我所拥有的基本上是一个公共共享资源(我的 singletonInstance.dll)。假设 appA 需要 singletonInstance,如果尚未实例化,它将实例化它。然后appB启动,它需要singletonInstance的引用。这就是场景。

Okay...I have a situation where a C# .dll is a singleton. Now, what I want to be able to do is when the singletonInstance is instantiated be able to provide a reference to any other applications that may start. So, I looked up NamedPipes and that would work - except for one thing, this must be cross-platform, or platform independent. I have a solution in mind, but I am having a hard time trying to figure out if I can derive a reference to the singletonInstance either through a handle, or some other method?

Now that there have been a few comments and questions, I can explain a little more and clarify: what I have is basically a commonly shared resource (my singletonInstance.dll). Say appA needs that singletonInstance, if it isn't yet instanced, it will instance it. Then appB is started, and it needs a reference to the singletonInstance. That is the scenario.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

金兰素衣 2024-08-25 06:22:31

如果我正确地阅读了本文,您应该在服务器上管理实例,并让其他应用程序与服务器而不是对象本身进行通信。我首先想到的是网络服务,但我对您的问题了解不够。

If I'm reading this correctly, you should manage the instance on a server and have the other applications talk to the server instead of the object itself. Web services is the first thing that comes to mind but I don't know enough about your problem.

纵山崖 2024-08-25 06:22:31

好吧,您可以通过命名管道进行通信,当它们不可用时,您可以使用套接字,但这取决于您的“单例”实际上要做什么。它是某种共享缓存吗?或者什么?

单独的应用程序和“单例”是否会在同一台计算机或网络中运行?无论如何,如果您想控制低级实现,或者您可以使用一些开销的 Web 服务或使用远程处理,那么套接字的方法是很好的。

Well, you can comunicate through named pipes and when they're no available you can go to sockets, but it depends on what actually your "singleton" is going to do. Is it some kind of shared cache? Or what?

Will separate applications and "singleton" run on same machine or in network? Anyways socket's approach is good if you want to control low level implementation or you can go to webservices with some overhead or use remoting.

诺曦 2024-08-25 06:22:31

听起来您最好将需要共享的任何内容实现为服务。

您可以通过选择公开/实施/允许的多种方式连接到服务。 Web 服务、WCF、命名管道或原始套接字等。选择最适合您的方式。

然后,服务本身可以适当地管理其内部状态(单例反模式或其他,这是不相关的)。

想想 Sql Server 是如何架构的。它不跨进程和内存边界共享相同的 dll 实例,也不使用繁重的客户端。

It sounds like you're better off implementing whatever needs to be shared as a service.

You can connect to the service in a variety of ways that you choose to expose / implement / allow. Web Services, WCF, Named Pipes or raw sockets, etc. Choose whatever works best for you.

The service itself can then manage it's internal state appropriately (singleton anti-patterns or otherwise, it's irrelevant).

Think about how Sql Server is architected. It's not sharing the same dll instance across processes and memory boundaries, nor is it using heavy clients.

听,心雨的声音 2024-08-25 06:22:31

我将提供一个答案 - Runtime.Remoting.Channels。我有一个公共数据对象(“singletonInstance”)继承 MarshaByRefObject。这正是我们想要的,而且我们还让它具备了一些网络功能。现在,这确实像一项服务。 TcpChannel“服务器”实际上是公共数据对象所在的 .dll 的一部分。这主要用于测试、实验实施等。

I'll offer up an answer - Runtime.Remoting.Channels. I had a common data object (the 'singletonInstance') inherit MarshaByRefObject. This gives us exactly what we want, plus we are making it capable of some networking features. Right now, this really acting like a service. The TcpChannel 'Server' is actually part of the .dll where the common data object is. This is mostly just for testing, experimental implementation, and so on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文