blocks|key|1545969|text|与当前的C#替代方案相比，WPF更易于设计、实现和维护，因此，如果您的许多代码库负责处理UI，迁移可能会有所帮助--正如在中所示，您会发现您的团队在处理UI层方面将节省时间。如果您的大部分代码都是业务逻辑，那么它不会有太大帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1545970|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

WPF UI's are easier to design implement and maintain than the current C# alternatives, so if a lot of your codebase is responsible for handling UI, migrating may serve beneficial-- as in, you'll find your team will save time in dealing with their UI layer. If most of your code is business logic, it won't help all that much.

blocks|key|1546010|text|我认为你原来问题的关键词是“花哨”。如果你的客户真的希望交付成果中有很多亮点，那么你可能会从切换到WPF中获得一些好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1546011|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I think the key word from your original question is "fancy". If your customers really expect a lot of glitter in the deliverable, then you probably do have something to gain from switching to WPF.

blocks|key|1546059|text|WPF是设计UI的一种非常新的方法。唯一的问题是它引入了大量的概念，其中一些只是为了隐藏XAML+(XML)的冗长。它还受到了architecture+astronaut设计方法的影响，但总的来说，我对它相当满意。它使你以前说不会做的事情，变成了可以管理的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1546060|entityMap|0|LINK|mutability|MUTABLE|url|http://www.joelonsoftware.com/articles/fog0000000018.html^0|1R|M|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

WPF is a very fresh approach to designing UIs. The only problem is that it introduces a large amount of concepts, some of those only to hide the verboseness of XAML (XML). It also suffers a little from an <a href="http://www.joelonsoftware.com/articles/fog0000000018.html" rel="nofollow noreferrer">architecture astronaut</a> approach to the design but overall I'm pretty happy with it. It makes things that you before would have said no way to, into something that is manageable to do.

blocks|key|1760998|text|WPF可以让你做一些令人惊叹的事情，我喜欢它...但每当开发人员问我是否认为他们应该转向新技术时，我总是觉得有义务对我的建议进行限定。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1760999|您的开发人员是否愿意(最好是急切地)花时间学习如何有效地使用WPF？我从来没有想过要对MFC、Windows+Forms甚至非托管DirectX说这些话，但您可能不希望一个团队在正常的开发过程中尝试“使用”WPF。一个运输产品的循环！|1761000|您的开发人员中是否至少有一两个具有设计敏感度，并且具有最终设计权威的个人是否对开发问题有良好的理解，这样您就可以利用WPF功能来创建实际上更好的东西，而不仅仅是更“多彩”，具有不必要的动画功能？|1761001|是否有一定百分比的目标客户群运行在可能不支持您计划的功能的集成图形芯片组上--或者他们仍在运行Windows+2000，这将使他们完全失去客户身份？有些人还会问，你的客户是否真的关心增强的视觉效果，但是，在经历了公司内部在20世纪90年代初“我们的业务客户不关心颜色和图片”的争论之后，我知道来自你的竞争对手的精心设计的解决方案会让他们关心，真正的问题是，条件是否合适，使你现在能够提供一些让他们关心的东西。|1761002|该项目是否涉及基础开发(至少对于表示层)，以避免尝试挂钩到不兼容的遗留脚手架的额外复杂性(与Windows窗体的互操作性不是无缝的)？|1761003|你的经理能接受(或分心)四到六个月内开发人员生产率的显着下降吗？|1761004|最后一个问题是由于我认为WPF的"FizzBin“性质，有十种不同的方法来实现任何任务，并且没有明显的理由偏爱一种方法而不是另一种方法，也没有什么指导可以帮助你做出选择。无论您做出什么选择，其缺点都只有在项目后期才会变得清晰，而且几乎可以保证您的项目中的每个开发人员都会采用不同的方法，从而导致主要的维护难题。最令人沮丧的是，当您尝试学习框架时，经常会遇到不一致的问题。|1761005|您可以在我的博客中找到更深入的WPF相关信息：|1761006|http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx|offset|length|1761007|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|0|0|0|0|0|0|1N|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|13|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|14|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|16|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|17|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|18|8|@]|9|@$R|19|S|1A|1|1B]]|A|$]]|$1|T|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|Q]]]]

WPF enables you to do some amazing things, and I LOVE it... but I always feel obligated to qualify my recommendations, whenever developers ask me whether I think they should be moving to the new technology.

Are your developers willing (preferably, EAGER) to spend the time it takes to learn to use WPF effectively? I never would have thought to say this about MFC, or Windows Forms, or even unmanaged DirectX, but you probably do NOT want a team trying to "pick up" WPF over the course of a normal dev. cycle for a shipping product!

Do at least one or two of your developers have some design sensibilities, and do individuals with final design authority have a decent understanding of development issues, so you can leverage WPF capabilities to create something which is actually BETTER, instead of just more "colorful", featuring gratuitous animation?

Does some percentage of your target customer base run on integrated graphics chip sets that might not support the features you were planning -- or are they still running Windows 2000, which would eliminate them as customers altogether? Some people would also ask whether your customers actually CARE about enhanced visuals but, having lived through internal company "Our business customers don't care about colors and pictures" debates in the early 1990s, I know that well-designed solutions from your competitors will MAKE them care, and the real question is whether the conditions are right, to enable you to offer something that will make them care NOW.

Does the project involve grounds-up development, at least for the presentation layer, to avoid the additional complexity of trying to hook into incompatible legacy scaffolding (Interoperability with Windows Forms is NOT seamless)?

Can your manager accept (or be distracted from noticing) a significant DROP in developer productivity for four to six months?

This last issue is due to what I like to think of as the "FizzBin" nature of WPF, with ten different ways to implement any task, and no apparent reason to prefer one approach to another, and little guidance available to help you make a choice. Not only will the shortcomings of whatever choice you make become clear only much later in the project, but you are virtually guaranteed to have every developer on your project adopting a different approach, resulting in a major maintenance headache. Most frustrating of all are the inconsistencies that constantly trip you up, as you try to learn the framework.

You can find more in-depth WPF-related information in an entry on my blog:

<a href="http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx" rel="nofollow noreferrer">http://missedmemo.com/blog/2008/09/13/WPFTheFizzBinAPI.aspx</a>

blocks|key|1761033|text|WPF从根本上不同于Windows窗体。这意味着你的团队需要进行大量的培训。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1761034|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

WPF is radically different from Windows Forms. This means a lot of training for your team.

We make infrastructure services (data retrieval and storage) and small smart client applications (fancy reporting mostly) for a commercial bank. Our team is large, 40 odd contractual employees that are C# .NET programmers. We support 50 odd applications and systems that we have developed. 

A few members of the team began making <a href="http://en.wikipedia.org/wiki/Windows_Presentation_Foundation" rel="nofollow noreferrer">WPF</a>, <a href="http://en.wikipedia.org/wiki/Windows_Workflow_Foundation" rel="nofollow noreferrer">WF</a> and <a href="http://en.wikipedia.org/wiki/Windows_Communication_Foundation" rel="nofollow noreferrer">WCF</a> based applications. Given that they are the first, most members do not understand these technologies. What benefits do they convey that would overcome the cost of retraining the team?

Should my C# .NET team migrate to Windows Presentation Foundation?

Windows

我们为一家商业银行提供基础设施服务(数据检索和存储)和小型智能客户端应用程序(主要是花哨的报表)。我们的团队很大，有40多名合同制员工，他们都是C# .NET程序员。我们支持我们开发的50多个应用程序和系统。团队中的一些成员开始开发基于、和的应用程序。考虑到它们是第一个，大多数成员不了解这些技术。他们传达了什么好处，可...

问我的C# .NET团队是否应该迁移到Windows Presentation Foundation？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我的C# .NET团队是否应该迁移到Windows Presentation Foundation？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问我的C# .NET团队是否应该迁移到Windows Presentation Foundation？
EN