winform 应用程序的 MVP/MVC 与传统 n 层方法
我们有一大套应用程序，大多数是 C# 1.1，但至少有 10 个主要应用程序是 VB6 的。 我们正在开展一个项目，将 VB6 应用程序升级到 .NET 3.5。
所有 c# 1.1 应用程序都是使用传统的 n 层方法编写的。 UI 层实际上没有任何架构/分离。 大多数代码只是响应事件并从那里开始。 我想说，从可维护性的角度来看，它非常好，并且很容易遵循代码并跟上新应用程序的速度。
当我们移植 VB6 应用程序时，最初的想法是我们应该坚持现有的模式（例如 n 层）。
我想知道，是否值得打破模式并使用 MVP/MVC 模式开发 VB6 应用程序？ MVC/MVP winform 应用程序真的更容易维护吗？ 我从事过一个基于 MVC 的项目，并没有觉得它更容易维护，但这只是一个项目。
有哪些经验和建议？
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
伙计，如果某件事对你有用，那么你们就会对此感到满意，并且你的团队也符合它的规格。 为什么你需要改变？
MVC/MVP 听起来不错……那为什么我自己还在做 n-Tier 呢？
我认为在您将资源投入到这种新编程方式的实际开发之前......您应该考虑它是否适合您的团队。
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
如果您要移植 VB6 应用程序而不是完全重写，我建议您重点关注您的 Pri 1 目标 - 尽快进入 .Net 世界。 只要这样做就会为您的组织带来很多好处。
一旦到达那里，您就可以评估投资重新构建这些应用程序是否对您有利。
如果您正在进行完全重写，我建议您大胆尝试并采用 MVP/MVVM 模式的 WPF 应用程序。 WPF 将为您提供更好的视觉效果。 MVP/MVVM 模式将为您提供所有层（包括视觉层）的单元可测试性。 我还假设这些应用程序是相关的，因此您可能能够真正重用您的模型和视图。 （不过，我在这里可能是错的）
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
它移动了用户界面上可能仍然存在的一层薄薄的代码。 我说薄，因为从你的描述来看，你可能在其他地方有很多代码。
这使您能够对薄层代码进行单元测试。
更新 1： 我不建议在升级时重新构建架构，额外的努力最好花在自动化测试（单元/集成/系统）上 - 因为您必须测试升级无论如何都有效。 一旦测试到位，您就可以对应用程序进行逐步更改，并通过测试来支持更改。
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC 尤其不排除 n 层架构。
我们还有 ASP.NET 1.1 业务应用程序，我发现维护它真是一场噩梦。 当事件处理程序做任何他们喜欢做的事情时，也许调整其他控件，也许调用业务逻辑中的某些东西，也许直接与数据库对话，软件工作只是偶然的。
如果正确使用 MVC，您可以看到数据从数据库到 UI 以及向后流动的方式。 如果出现意外行为，可以更轻松地跟踪错误。
至少，我自己的小项目是这样。
我将再次强调这一点：无论您使用什么模式，都要坚持清晰的 n 层架构。 2 层或 3 层，只是不要把所有东西都弄乱成一个相互连接的大球。
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
“改变——我们所从事的活动是为了暗示进步。” - Dilbert
说真的，将您的开发环境和部署平台升级到 .NET 3.51 本身就是一大进步。 我建议在重新设计应用程序之前应该进行安全审查和代码演练之类的事情。
MVC 和 MVVM 是优秀的典范，特别是在可测试性方面。 不要忘记它们，但也许您应该在全面采用之前考虑一个试点项目？
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?