我们正在开发/维护一个企业应用程序，由于历史原因和开发加速，它已被定位为WinForms。在WinForms上开发思考未来Web开发的技巧
现在我们正在考虑迟早（早于或晚于）应用程序需要基于Web。
关于“到Web”运动的思考。哪些是我们必须考虑的最重要的事情？类似于MVP游戏（或其他）的事情，现在确定你将要使用的平台/框架类型，...
任何有关从winforms迁移到web的经验？任何建议要小心？
Aclaration：在我们的场景中，应用程序会很好，现在是基于Web的，但我们是真实的。我同意并非所有的应用程序都必须基于Web（这是我们使用WinForms开发的主要原因！）。但有时需求会发生变化，在我们的情景中，我们想要将该应用程序提供为SaaS。
最重要的是将用户界面完全分开。一旦你完成了，你将不会重写应用程序来移植它 - 你只需要在上面创建一个Web UI。
NESBAWA（并非所有应该都是Web应用程序）。
约翰是对的。 但是，您是否听说过“空客户”方法？这是开发.NET WinForms应用程序的一种相当新的方法，它也可以在普通浏览器上作为Web应用程序运行。这种方法可以让你开发你的WInForms应用程序，并且在你不需要额外的开发或调整的情况下，将它放到网络上。 这样做的一个框架是Visual WebGui
我曾为一家公司处理类似的情况，他们的单片WinForms应用程序。根据这个经验，有两件事需要考虑：
1]从现有的WinForms UI中解耦所有的数据访问逻辑（DAL）。您可以在任何Web开发开始之前启动此过程。
我们在一系列每周6次冲刺中完成了这个重构。应用程序的某些部分很容易更改 - 其他部分由完全地狱般的意大利面代码组成，它们在WinForm后面的代码中交织DAL，内联SQL和UI代码。
一旦你完成了这个分离，支持两个不同的UI就更容易了。
2]忽略ASP.Net MVC和目标WebForms。 WebForms旨在使编写Web应用程序接近编写传统WinForms UI代码（事件驱动，基于组件）的体验。
您需要了解页面生命周期，并且围绕动态生成的控件存在一些概念性陷阱，这些概念陷入了很多新手 - 但除此之外，它是让一组WinForms开发人员完成网络工作的最无痛的方式。 MVC现在在网络圈子中可能非常流行，它提供了一个更好的问题分离（尽管如果努力和强大的设计领导能力，您可以使用WebForms获得类似的结果），但它需要更高的知识水平。使用MVC，您正在接近HTTP请求/响应周期的金属。 WebForms为你抽象了很多。
祝你好运！
SIGTMWA（有时是迁移到Web应用程序的一件好事）。 – FerranB 2009-07-09 15:50:14