我们有一大套应用程序，大多数是 C# 1.1，但至少有 10 个主要的应用程序是 VB6。我们正在进行一个将 VB6 应用程序升级到 .NET 3.5 的项目。
所有 c# 1.1 应用程序都是使用传统的 n 层方法编写的。UI 层实际上没有任何架构/分离。大多数代码只是响应事件并从那里开始。我想说的是，从可维护性的角度来看，它非常好，并且很容易遵循代码并加快新应用程序的速度。
当我们移植 VB6 应用程序时，最初的想法是我们应该坚持现有的模式（例如 n-Tier）。
我想知道，是否值得打破模式并使用 MVP/MVC 模式做 VB6 应用程序？MVC/MVP winform 应用程序真的更容易维护吗？我在一个基于 MVC 的项目上工作，并没有觉得它更容易维护，但这只是一个项目。
有哪些经验和建议？
伙计，如果有什么东西适合你，你们会觉得很舒服，而且你的团队也符合规范。为什么你需要改变？
MVC/MVP 听起来不错……那我为什么还要自己做 n-Tier 呢？
我认为在您将资源投入到这种新的编程方式的实际开发中之前......您应该考虑它是否适合您的团队。
如果您要移植 VB6 应用程序而不是完全重写，我建议您专注于您的 Pri 1 目标 - 尽快进入 .Net 世界。这样做会给您的组织带来很多好处。
到达那里后，您可以评估投资重新架构这些应用程序是否对您有利。
如果您要进行完全重写，我会建议您尝试使用 MVP/MVVM 模式的 WPF 应用程序。WPF 将为您提供更好的视觉效果。MVP/MVVM 模式将为您提供所有层的单元可测试性，包括视觉。我还假设这些应用程序是相关的，因此您可能能够实际重用您的模型和视图。（虽然，我可能在这里错了）
它移动了你可能仍然在 UI 上的一层薄薄的代码。我说很薄，因为根据您的描述，您可能在其他地方有很多代码。这为您提供了对这一薄层代码进行单元测试的能力。
更新 1：我不建议在升级时重新架构，额外的努力最好花在获得自动化测试（单元/集成/系统）上 - 因为无论如何您都必须测试升级工作。一旦测试到位，您就可以对应用程序进行渐进式更改，并且可以轻松地通过测试来支持更改。
MVC 尤其不排除 n 层架构。
我们还有 ASP.NET 1.1 业务应用程序，我觉得维护它真是一场噩梦。当事件处理程序随心所欲地做任何事情时，可能会调整其他控件，可能会调用业务逻辑中的某些内容，可能会直接与数据库对话，这只是偶然的软件工作。
如果使用正确，使用 MVC，您可以看到数据从数据库流向 UI 和向后流动的方式。如果您遇到意外行为，则可以更轻松地跟踪错误。
至少，我自己的小项目是这样的。
我将再次强调一点：无论您使用什么模式，都要坚持清晰的 n 层架构。2-Tier 或 3-Tier，只是不要把所有东西都弄成一个相互关联的大球。
“改变——我们从事的活动是为了暗示进步。” - 呆伯特
不过说真的，仅仅将您的开发环境和部署平台升级到 .NET 3.51 本身就是一大步。我建议在重新设计应用程序之前可能应该先进行安全审查和代码演练。
MVC 和 MVVM 是极好的范例，特别是在可测试性方面。不要忘记它们，但也许您应该在全面采用之前考虑一个试点项目？