2

我正在将大型 vb6 应用程序移植到 .NET。当前应用程序是与一组本地访问数据库通信的桌面应用程序。应用程序中有大约 200 个表格和大约 100 个表格。屏幕大多是复杂的。大多数显示主从关系、嵌入式电子表格中的大量行和动态生成的编辑控件。

他们会将其移植到 .NET。我不确定他们是否会想要它基于 Web 或 winforms。对我来说，该应用程序似乎更适合 winforms。值得庆幸的是，无论选择如何，访问数据库都将替换为 sql server。

我使用winforms的原因：

  • 更丰富的用户界面。
  • 客户端缓存
  • 更快的发展。尽管 ASP.NET 比经典 ASP 的生产力高出数光年，但 Winforms 对我来说还是很有效率的。我还是宁愿在winforms中工作。
  • 可以显示更多数据并花费更少的时间来管理状态。

我计划将业务/数据层分解为一个单独的库。库中的业务对象将能够被 winforms 或 Web 应用程序使用。

我在想，如果我们先移植到 winforms 并且将 UI 和业务逻辑完全分离，我将能够在以后的 Web 版本中重用业务逻辑。鉴于业务/数据层位于一个单独的库中，没有 UI 依赖项。

最后，这不是我的决定，但我想听听您将大型 Windows 应用程序迁移到 asp.net 的经验。

将大型桌面应用程序迁移到 asp.net 是什么体验？你会如何处理这样的项目？您愿意将此应用程序移植到 winforms 或 asp.net 吗？为什么？

谢谢！史蒂夫

4

5 回答 5

3

移植到新的 ASP.Net Web 应用程序的一个主要优点是您将有更多的机会来清理它。

当迁移到 winforms 时，会有很大的诱惑和压力，只需要“逐屏移植”，而如果你使用 web，你将有机会在更基础的层面上进行重构和改进。

我的公司目前正在将一个相当大的旧版 VB6/Access 应用程序移植到 ASP.Net，并且通过 AJAX（现在是 Silverlight），现在可以在 Web 上的 UI 中获得非常高水平的视觉质量和复杂性。从用户访问和部署的角度来看，也有明显的优势。

至于如何处理该项目，我使用迭代方法取得了成功——构建一个薄片（实现单个功能）来证明架构，然后根据优先级和复杂性添加功能。

于 2009-02-28T02:26:25.863 回答
1

我建议您分阶段进行移植，以使过渡更容易。第一阶段是从 VB6 桌面移植到 .NET 桌面（win 形式）。

然后在第二阶段，如果仍然需要，您将全部或部分 .NET 桌面移动到 ASP.NET GUI。

无论 GUI 选择如何，从 VB6 到 .NET 的步骤本身对于团队来说都是相当大的。分阶段的方法将允许您的团队以更类似于当前应用程序的应用程序样式来掌握 .NET。

因此，您将业务逻辑分离为可重用库的目标对于这种分阶段的工作方法很重要。如果您采用这种方法，则您对所使用的 GUI 类型（或类型）具有更大的灵活性。

例如，您可以在 ASP.NET 网站中提供所有更简单的屏幕，并使用包含更复杂屏幕的辅助 WindowsForms 应用程序，用户可以根据需要下载这些屏幕。重要的是，它们都将使用相同的业务逻辑库，它们大多只是同一个应用程序的不同接口。

ASP.NET（或一般的 Web 开发）在处理状态、跨浏览器、html/css 等时需要完全不同的开发人员思维方式。

我最近致力于将大型 Delphi 桌面应用程序移植/迁移到 .NET。目标是使用 ASP.NET，但是这完全失败了，因为现有团队的 Web 开发经验有限，并试图使用 ASP.NET 重新实现桌面应用程序。我想说，与在 Windows 窗体中重新创建屏幕相比，这是一个更大的风险，至少最终结果将是可用的并为最终用户提供一些价值。

虽然 Ajax 和 jQuery 对丰富的 Web GUI 做出了很大的改进，但听起来您现有的应用程序有一些领域，例如数据的电子表格表示，在桌面应用程序中更容易有效地实现。

总而言之，“理想”是将业务逻辑和规则移至 .NET，以便您以后可以简单地“插入”用户界面。这可能说起来容易做起来难，但这是我通常的目标。

于 2009-02-28T02:30:25.837 回答
0

我只能说你不应该重新开始！在其中一个 StackOverflow 播客中，主题是您是否应该重写应用程序以获得新语言的好处，答案是否定的！Joel Spolsky 给出的例子是 Borland C++ Builder。他们输给了 Microsoft VC++，因为他们从头开始。然后 Jeff Atwood 继续说，尽管 WordPress 是用 PHP 编写的（我认为这不是一种好语言），但总体思路还是成功了。

要点：
不要重新开始，因为你失去了在坚实基础上获得的所有经验。

于 2009-02-28T03:31:13.447 回答
0

首先，Winforms 已经死了。WPF 已经问世将近两年了，为什么有人会用 WinForms 开始一个新的桌面程序，这让我无法理解。为什么要将您的客户从一种非常非常过时的技术 (VB6) 转移到另一种很快就会过时的技术？请不要误会，但除非您必须支持比 XP 更早的 Windows 版本，否则我认为在 2009 年启动 WinForms 项目实际上是不负责任的。以下是与 WPF 相比的缺点：

  1. XAML、WPF 和 Silverlight 是微软的重点。
  2. WPF 在图形方面比 Winforms 强大得多（至少就开发非常丰富的 UI 而言）。
  3. WPF 中的数据绑定是 Winforms 的一大飞跃；它会节省你的时间。
  4. WPF 是稳定的，并且在过去的几个 SP 和版本中已经看到显着的性能提升。
  5. 像所有旧的 MS 技术一样，Winforms 迟早会消亡。这显然是现在的旧技术。

现在为 ASP.Net。这听起来像您正在转换的是一个相当简单的内部应用程序。ASP.Net 就是适合这样的事情。虽然 ASP.Net MVC 几乎已完成测试，但它还没有 WPF 反对 WinForms 的反对 ASP.Net 的论据。我们在工作中使用 ASP.Net + jQuery，效果很好。我们也在做 Silverlight，你可以看看。我真的很喜欢在里面工作。如果这是一个内部应用程序，您可能可以指望安装在所有浏览器上的 Silverlight 插件。

现在对于去WPF vs ASP.Net的一般优点：

WPF

  1. 更容易将代码从 VB6 桌面迁移到另一个桌面环境。尽管需要将其转换为 VB.Net 或 C#，但您可能可以节省大量逻辑。您正在从一个有状态的环境转到另一个。ASP.Net 并非如此。
  2. 更容易测试（特别是如果您必须支持多个浏览器）。
  3. 开发速度可能更快（特别是如果您必须支持多个浏览器）。

ASP.NET

  1. 比桌面应用程序更容易分发更新（您所做的就是更新您的网络服务器）。
  2. 如果创作正确，可以在各种台式机甚至移动设备上使用。
  3. 可以通过额外的开发工作来提供桌面应用程序的大部分动态特性。
  4. 可用于可能面向公众的未来产品。

祝你的项目好运！

于 2009-02-28T05:21:04.697 回答
0

如果您真的想发疯，并且不介意使用最新技术，请查看 ASP.NET 和 Silverlight 3。查看Mix 09的视频，有一些很好的例子可以解决这个问题。

此外，Silverlight 应用程序可以在浏览器之外运行，因此能够提供桌面体验，但具有在您更新代码等时更新的优点。而且我个人认为 Windows 类型的应用程序（包括 Silverlight）是比基于 Web 的应用程序更适合数据输入（尽管使用 Ajax 确实有帮助）

于 2009-03-28T09:29:38.017 回答