如何为Windows 8构建企业桌面应用程序

我认为我对Windows 8消费者应用程序开发的期望有所了解。在WinRT之上创建一个新的基于Metro的UI，通过Marketplace将其部署到您的客户中，每个人都将赢得胜利。似乎很简单。不幸的是，我不从事这项业务。

我为大型企业开发内部业务线应用程序。当前，我们使用诸如WPF和Silverlight之类的.NET技术来创建可通过Web或ClickOnce轻松部署给我们用户的丰富UI。这些应用程序可以轻松支持WinXP和Win7，并且我们的开发人员可以使用XAML，这是一种非常可靠的UI技术。

WPF和Silverlight似乎在这一点上有可疑的期货，因此继续投资于这些股票有点令人担忧。但是Metro UI似乎不适用于企业应用程序，并且WinRT API在企业应用程序需要做的“典型”事情上有很大的局限性。

我应该如何设计当前已部署到WinXP和Win7的基于XAML的应用程序，以便它们在Win8上可支持并可以发展？

出于这个问题的目的，假设ASP.NET之上的HTML5提供的功能不足以适合我要创建的应用程序。我知道我可以在某些应用程序中使用HTML5，但我试图弄清楚在不够的情况下应该怎么做。

编辑1： 这是对@Emmad Kareem的评论的回应。我同意Silverlight / WPF在短期内（2-5年）是可行的。但是，我们生产的应用程序的使用寿命可能非常长（10-20年以上）。因此，给定技术的长期生存能力是我们关注的问题。另外，我们担心，如果社区认为“ Silverlight / WPF开发”中的技术“过时”，那么找到对它们感兴趣的开发人员将越来越困难。我只是想了解我的选择，睁开眼睛做出决定。

我如何学会停止担心和热爱MS-Stack

您仍然可以在Windows 8上运行VB6应用程序。不论好坏，逆向兼容一直是MS生态系统的趋势。您不必担心WPF / Silveright等技术的生存，甚至不必担心Winforms的生存。

另一方面，您必须接受一个长期项目，永远不会拥有最新，最可爱的技术。

实际上，关于技术选择，您应该问自己的问题是：

• 我的团队是否足够满意该技术以提高生产力？
• 我的团队乐于使用该技术吗？
• 我可以为此技术招募人员吗？

这是对这些问题的答案的组合，应该会引导您做出选择，而不是主要出于营销原因而形成的趋势。

有关不断变化的技术主题的更多信息，您应该阅读Joel Spolsky的“ Fire And Motion”：

那些陷入困境的公司就是那些花太多时间阅读茶叶以找出微软未来方向的公司。人们担心.NET并决定重写.NET的整个体系结构，因为他们认为自己必须这样做。Microsoft正在向您射击，这只是掩盖之火，因此他们可以前进而您不能前进，因为Bubby是游戏的玩法。您要支持冰雹风暴吗？肥皂？RDF？您是否支持它是因为客户需要它，还是因为有人在朝您开枪而您感觉必须做出回应？大公司的销售团队了解掩护。

那是近十年前写的。

建筑与技术

体系结构和技术是要做的两个独立的事情和选择：

• 您可以使用winforms进行MVC。
• 您可以使用WPF / Silverlight进行MVVM。
• 您可以使用ASP.NET进行MVC。
• 据我们所知，您可以使用WINRT做任何您想做的事情，包括MVC和MVVM。
• 您可以使用F＃实现功能。为什么不 ？在某些领域是有意义的。
• 您可以将所有这些混合使用，以使一个通用系统具有不同的入口点，然后由于过于复杂而被嘲笑，等等。

您可以将服务，资源，第三方控件，ORM等与所有这些技术一起使用，也可以与下一个技术一起使用，也可以不使用。

您可以使用所有这些技术以多种方式扭曲和弯曲MVC：是否绑定？代码是否在视图后面？控制器与否？每次或仅在需要时使用ViewModel吗？即使在一项特定技术的范围内，实现设计模式的方法也有很多。

如果没有对项目和团队的深入了解，将您逼入其中之一将是不现实的。它只会基于个人喜好，最终会出现“我的技术比你的技术更好”的摊牌。

可以诚实和客观地建议的唯一方法是，使用可以应用的最佳实践来创建经受时间考验的体系结构，也许，实际上，它可能会被移植或至少在未来的未知技术中重复使用。 。而且，可升级性/可移植性甚至不应该是体系结构的主要目的。

您的体系结构和所选技术的主要目的是向您的老板/客户提供满足其实际需求的产品。

自1979年以来，MVC（以及它的弟弟MVVM）在OOP语言领域及以后逐渐被证明是健壮体系结构的基础。但是，在10年的项目中选择应使用的特定技术仍然是您的决定。

我将在有关MVVM的书中谈到的一件事是如何利用该模式创建可重用的核心应用程序。您应该为目标平台（Web，Silverlight，电话，WPF或WinRT）创建本机UI。但在大多数情况下，您可以将驱动该UI的逻辑封装在ViewModel之后。

您访问的任何服务都应包装在一个界面（立面模式）的后面，该界面在平台之间或多或少具有可移植性。该接口应在前面映射到您的客户端API，并在后面转换为包装服务的API。

此策略可帮助您创建一个坚实的核心框架，该框架仅需要在其上分层放置新的UI。可以将其视为您的视图模型是肌肉，您的服务就是骨骼（和器官）的骨架。WPF / Silverlight / WinRT形成皮肤。

实际上，我在书中很早就指出的一件事是MVVM并不像看起来的那么新。Dolphin Smalltalk具有类似的模式，他们称之为MMVC（两个M是应用程序模型和域模型）。我们今天使用的ViewModel只是MMVC的Application Model和Controller的组合。实际上，许多开发人员发现有时将ViewModel分成两个组件是很有意义的（该控制器用于导航和编排多个VM，以便VM可以幸福地保持对其他组件的意识）。

您说XAML是可靠的，但随后说WPF的前景令人怀疑。除非我缺少某些东西，否则WPF使用XAML，而且我看不到两者是分开的。关于WPF是否可能使用某些其他基本技术，或者关于Microsoft，甚至可能考虑构建另一种构建UI的新方法，我是否缺少一些消息？除此之外，我怀疑WPF到哪里去了，但这不是MS第一次废弃我们的代码。

如果您需要一个丰富的UI应用程序并且HTML5不会削减它，并且您是组织致力于Windows OS，我认为WPF是最好的选择，因为它是目前为止最新/最强大的工具，当然是在Winforms上...

我对此的看法是，您不应过多地关注应用程序的实现细节。如果从更大的角度看，则可以隔离技术依赖性。通过isolatin对xaml / wpf / silverlight的依赖，您可以确保可以用下一代技术替换ui组件/技术，从而即使在20年的时间里也可以保证连续性。这也将有助于解耦系统组件，从而避免必须执行此类替换的影响。（在此我假设，为了提供连续性，可以修改解决方案以使其在下一代平台上运行是可以的）

提供与这些技术依赖关系隔离的另一种方法是启用虚拟化。如果您以能够在虚拟机中运行它们的方式来设计应用程序，那么您将能够在20年后完成！