我们正在开发/维护一个企业应用程序，由于历史原因和开发速度，它被定位为 WinForms。
现在我们正在考虑迟早（迟早）该应用程序将需要基于 Web。
思考“to-Web”运动。哪些是我们必须考虑的最重要的事情？类似于 MVP 游行（或其他）的事情，现在确定您要使用的平台/框架类型，......
有从winforms迁移到web的经验吗？有什么建议要照顾吗？
声明：在我们的场景中，应用程序现在可以很好地基于 Web，但我们是现实的。我同意并非所有应用程序都必须基于 Web（这是我们使用 WinForms 开发的主要原因！）。但有时需求会发生变化，在我们的场景中，我们希望将该应用程序作为SaaS提供。
最主要的是将用户界面与其他一切完全分开。一旦你这样做了，你就不会为了移植它而重写应用程序——你只是在上面创建一个 Web UI。
NESBAWA（并非所有东西都应该是 Web 应用程序）。
我曾在一家公司工作，他们的单体 WinForms 应用程序也遇到过类似情况。从这个经验来看，有两点需要考虑：
1] 将所有数据访问逻辑 (DAL) 与现有 WinForms UI 分离。您可以在任何 Web 开发开始之前开始此过程。
We did this refactoring in a series of 6 weekly sprints. Some parts of the app were easy to change - others were made of completely hellish spaghetti code that interwove DAL, inline SQL and UI code all in the code behind of the WinForm.
Once you have this separation in place, supporting two different UIs is easier.
2] Ignore ASP.Net MVC and target WebForms. WebForms was designed to make writing a web application close to the experience of writing traditional WinForms UI code (event driven, component based).
You need to understand the page lifecycle, and there are a few conceptual gotchas around dynamically generated controls that tend to trip up a lot of newcomers - but otherwise it's the most painless way to get a team of WinForms developers doing web stuff. MVC maybe very popular in web circles right now, and it provides a better separation of concerns (though you can achieve similar results with WebForms with a bit if diligence and strong design leadership) - but it requires a higher degree of knowledge. With MVC you're working closer to the metal of the HTTP request/response cycle. WebForms abstracts away a whole lot of that for you.
Best of luck in your endeavour!
约翰是对的。但是，您听说过“空客户端”方法吗？这是一种相当新的开发 .NET WinForms 应用程序的方法，它也可以作为 Web 应用程序在普通浏览器上运行。这种方法将允许您开发您的 WInForms 应用程序并在您需要时将其放到 Web 上，而无需额外的开发或调整。一个框架是Visual WebGui