Web 应用程序与遗留代码的互操作

发布于 2024-08-13 12:32:35 字数 1061 浏览 5 评论 0原文

我正在尝试将简单的 WinForms 应用程序迁移到 ASP.Net Web 应用程序。 WinForms 应用程序基本上只是复杂的纯 C 应用程序的表示层,并通过 COM 互操作与遗留代码进行交互。我在 ASP.Net、javascript、jQuery 方面有一定的经验,在 WinForms 和互操作方面也有丰富的经验,所以我了解基础知识,我只需要做出设计决策。

该应用程序现在的样子是这样的:

  1. 有一堆遗留的 C(甚至不是 C++)代码,可以更改和重新编译,但不能进行移植。这是业务+数据层,你想怎么称呼它就怎么称呼它。我将其称为遗留代码

  2. 启动时,遗留代码会实例化一个用于演示和用户交互的 COM 服务器。演示数据被序列化并发送到此 COM 对象(“我正在向您发送一些输出。”),并且用户交互是通过循环轮询实现的(“您有一些输入要给我吗?” ?”)。这不是最漂亮的解决方案,但非常简单。

  3. COM 对象实际上是一个公开为 COM 的 .NET 2.0 WinForms 应用程序。此应用程序还通过 .NET Remoting 向其他 .NET 应用程序公开一些功能,但这也不是那么重要。

虽然系统比较复杂,但WinForms应用程序实际上只是用于交互,因此切换到Web非常容易。我不确定什么是执行网络服务器的最佳方式<--->遗留代码交互。

我想到的第一件事(因为我已经实现了 .NET Remoting)是通过本地 .NET Remoting 将 WinForms 功能公开给 Web 部件,使其充当遗留代码和 Web 应用程序之间的某种代理。我实际上只需要沟通部分,不需要表格。在这种情况下,Web 应用程序必须通过 .NET Remoting(本地)访问此功能。

让 Web 应用程序使用 .NET Remoting 在本地与另一个应用程序进行通信是否明智?另外,我可以将应用程序更改为 Windows 服务,但我仍然能够通过 COM 将其功能公开给旧代码吗?

实现这一目标的更好方法是什么?请注意,如果需要,我还可以对遗留代码进行一些修改。

I am trying to migrate a simple WinForms app to a ASP.Net web app. WinForms app is basically only a presentation layer for a complex plain C app, and interacts with legacy code through COM interop. I have modest experience in ASP.Net, javascript, jQuery, and lots of experience in WinForms and interop, so I know the basics, I just need to make a design decision.

The way the app looks right now is this:

  1. There is a bunch of legacy C (not even C++) code which can be changed and recompiled, but porting is not an option. This is the business+data layer, call it what you want. I'll refer to it as legacy code.

  2. When started, legacy code instantiates a COM server which is used for presentation and user interaction. Presentation data is serialized and sent to this COM object ("I'm sending you some output."), and user interaction is achieved through cyclic polling ("Do you have some input for me?"). Not the prettiest solution but simple as hell.

  3. COM object is actually a .NET 2.0 WinForms app exposed as COM. This app also exposes some functionality to other .NET apps through .NET Remoting, but that is not so important also.

Although the system is rather complicated, WinForms app is really used for interaction only, so it's pretty easy to switch to web. What I am not sure is what's the best way to do the web server <---> legacy code interaction.

The first thing that comes to my mind (since I already have .NET Remoting implemented) is to expose the WinForms functionality to the Web part through local .NET Remoting, making it act like some sort of a proxy between legacy code and web app. I would actually only need the communication part, without forms. In that case, web app would have to access this functionality through .NET Remoting (locally).

Is it wise to have web app communicate locally to another app using .NET Remoting? Also, I could change the app to a Windows service, but would I still be able to expose its functionality through COM to legacy code?

What would be a better way to achieve this? Note that I can also make some modifications to the legacy code if needed.

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

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

发布评论

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

评论(2

灰色世界里的红玫瑰 2024-08-20 12:32:35

我认为对您来说一个重要的方面是 WinForms 应用程序的单用户性和 Web 的多用户会话性。

10 年前,我参与了几个 Web 项目,我们在 MTS 和后来的 COM+ 中将业务逻辑作为 COM 对象 (VB6) 运行。让这些 COM 对象属于会话是一个禁忌,因为如果用户频繁来来去去,最终可能会导致大量资源被未使用但仍处于活动状态的 COM 对象所占用。

我建议您考虑在组件服务中运行 COM 对象。这可能不是解决方案,但值得探索。

将 COM 对象放入组件服务中就像编写一个可通过 COM 访问的 Windows 服务一样——我会为 y 中的所有 x 触摸它:其中 x 是最喜欢的食物,y 是最喜欢的地方。

.Net Remoting 很棒,但最有趣的是作为一种通信设备。我不知道你是否打算将其拆分到许多服务器中,这听起来像是公司内部应用程序。我没有足够的细节来更具体。

I think that one important aspect for you is the single-userness of a WinForms app and the multi-user-sessionness of web.

10 years ago I was involved in several web projects where we ran the business logic as COM objects (VB6) in MTS and later COM+. Letting those COM objects belong to sessions were a no-no, because if users come and leave a lot you could end up with a lot of resources tied up in unused but living COM objects.

I would suggest that you look into running your COM objects in Component Services. It might not be THE SOLUTION, but it is worth exploring.

Putting COM objects in Component Services is as close you can get to writing a windows service that is reachable through COM - something I would touch for all the x in y : where x is favourite food and y is favourite place.

.Net Remoting is wonderful, but mostly interesting as a communication device. I don't know if you are going to split up this in many servers, it sounds like a company internal application. I don't have enough details to be more specific.

以往的大感动 2024-08-20 12:32:35

看来您应该尝试寻找方法,通过 ASP.NET 基础结构简单地重用简单的 WinForms 代码。这意味着您可能不需要重新编写 UI 代码,而只需在 Web 上的 WinForms 的某些模拟基础设施上按原样使用它。

请参阅我对一个完全可以做到这一点的框架的直接建议:
这个

我希望 帮助……

It seems like you should try to look for away to simply reuse your simple WinForms code over ASP.NET infrastructure. This means that you will probably will not need to re-write the UI code but just use it as-is on some emulative infrastructure of WinForms over web.

Please see my immediate suggestion of a framework that does exactly that:
http://www.visualwebgui.com/landing/wow.aspx

I hope this helps…

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