Legacy VC＆＃x2B;＆＃x2B;，基于COM的桌面应用程序，使用微服务
我正在将现有桌面应用程序移至Web的过程中。 GUI是使用MFC/VC ++开发的，并且Buisness逻辑以COM启用VC ++ DLL编写。该DLL负有各种责任。当前，此DLL是作为桌面应用程序内存的一部分加载的。现在，我正处于将此应用程序移至现代Web应用程序的初始阶段。以下是到目前为止考虑设计的思维过程，
- 将单片业务逻辑转换为微服务。
- 将微服务部署在服务器中。
- 我的业务逻辑VC ++ com层可以与微服务接口并获取数据。
- 拥有一个可以与微服务通信的API网关，并且可以与Web客户端一起使用。
在此过程中，我想尽可能多地重复使用VC ++ COM业务逻辑层。当前的COM DLL不支持多线程或多用户会话。这需要得到支持。接下来的事情将是在网络中重复使用现有的MFC GUI。
可以考虑哪些技术重用我的业务逻辑？
I am in the process of moving my existing desktop application to web. The GUI is developed using MFC/VC++ and the buisness logic is written in COM enabled VC++ DLL. This Dll has various responsibilities. Currently this Dll is loaded as part of the desktop application memory.Now I am in the initial stage of moving this application to modern web application. Below is the thought process for design considered till now,
- Converting monolithic business logic to micro services.
- Deploy the micro services in a server.
- My business logic VC++ Com layer can interface with microservices and get data.
- Have a API gateway which can communicate to microservices and it can serve to the web client.
In this process I wanted to reuse VC++ Com business logic layer as much as possible. The current com Dll is not supporting multi threading or multi user sessions. This needs to be supported. The next thing would be reusing existing MFC GUI in web.
What are the technologies can be considered to reuse my buisness logic?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于最多的代码恢复，我认为您在正确的轨道上。
您绝对想将业务逻辑分为自己的服务，并且可以通过您喜欢的任何通信协议来公开该服务。最大的缺点是，每次都需要添加功能，需要在两个位置添加，或者在这种情况下三个：业务逻辑服务器，MFC服务器和Web服务器。
正如其他人指出的那样，MFC确实是用于桌面应用程序的。 “现代Web应用程序”是无状态的，并通过通过HTTP（S）进行消息进行通信，Web浏览器是客户端。网络中确实没有重新使用MFC GUI。架构太断开了。
话虽如此，但我还没有太多研究，但是《大火》是WASM编译器。它对.NET框架的支持有限，甚至在交流部分周围甚至不太支持，但是它可以能够编译您的项目。但是，我敢打赌。
我认为您最好只专注于与水疗中心的体面的网络体验并放弃MFC/桌面部分。也许以后您可以通过MAUI或WPF循环并构建GUI，从而消耗Web API。
For the most code-reuse I think you're on the right track.
You definitely want to separate out the business logic into it's own service and you can expose that via any communication protocol you prefer. The biggest downside to this is that every time functionality needs to be added, it needs to be added in two places, or in this case three: the business logic server, the MFC server, and the web server.
As others have pointed out, MFC was really intended for desktop applications. A "modern web application" is one that is stateless and communicates via message-passing over http(s) with the web browser being the client. There's really no re-using the MFC GUI in the web. The architectures are just too disconnected.
Having said that, and I haven't looked into it too much, but Blazor is a WASM compiler. It has limited support for the .net framework, even less so around the communication portion of it, but it might be able to compile your project. I'd bet against it, however.
I think you'd be better off just focusing on a decent web experience with a SPA and abandoning the MFC/Desktop portion. Maybe later you can circle back and build a GUI through MAUI or WPF that consumes the web API.