转:创建多界面的应用程序 (好文章)
类别: ASP.NET教程 
创建多界面的应用程序
提前设计应用程序，使其满足用户对不只一个界面的需求。
by Robert Ericsson and Jason Cline
涉及技术：.NET Framework, ASP.NET, Windows Froms, .NET Compact Framework, Mobile Internet Toolkit
下载本文代码(http://www.fawcette.com/China/DotNetMagazine/2002_12/code/nm0212re.zip)
对于你们开发小组开发的软件，你可能想给用户提供最佳的用户界面，这就意味着你需要不只一个界面。用户希望可以在任何时候、任何地点、在各种设备上访问信息。这就形成了人们对灵活界面的需求，而且使应用程序的基本原理和用户界面的设计和创建显得更为重要了。在本篇文章中，我们将讲述一些用来定义、设计、构建和测试支持.NET多个用户界面的应用程序的最好的方法。我们的探讨只局限于现有的以及很快会实现的用于.NET平台的开发技术。然而，如果你们的开发团队已经创建了一个Java前端系统，并通过.NET Web services来运行一个服务器端应用程序的话，这些方法也同样适用。
在Rob Ericsson的“为好的UI 选择合适的工具”(http://www.fawcette.com/China/XmlFile.aspx?ID=25)一文中，他讲述了应用程序的一些特点，可以帮你选择是用Windows Forms还是用ASP.NET来实现一个应用程序。这种选择的要点就是要对每种技术进行成本效益分析，将应用程序的可用性作为一个最重要的因素来考虑。然而，这通常并不是一个简单的二选一的问题。有时侯，一个应用程序有很多不同的用户群。所以，用户的需求以及他们对用户界面的需求会有很大的差别就不足为奇了。对于这种类型的应用程序，“一刀切”（one-size-fits-all）式的Windows Forms或ASP.NET实现方式可能就不太适合了。
在这种情况下，你应该考虑创建一个可以提供多个用户界面的应用程序。对于这种具有多个界面的应用程序，我们可以将Microsoft Exchange Server作为例子来讲述：Outlook是Windows客户端，Outlook Web Access （OWA）是基于Web的界面。你临时不在办公室时使用OWA是很理想的，而Outlook Windows客户端是设计用于大量的日常工作的。然而，不同的界面并没有必要用不同的技术来构建。让我们来看一个客户服务中心的应用程序。客户服务电话接线员运用的数据录入界面同用来管理应用程序的界面有很大的不同，虽然它们都是用Windows Forms构建的。实际上，运用相同的界面技术来创建两个不同的界面比将多个界面技术整合到一个应用程序中要简单得多。
认可困难
虽然一些工具供应商认为创建具有多个用户界面的应用程序很简单，但事实并非如此。很多时候，创建一个Web或PDA应用程序所带来的兴奋感都会让开发人员失去理智，从而不去考虑Windows应用程序是否对用户更有效。另外添加一个界面会给你的应用程序带来许多复杂的问题，所以不要轻易作出这样的决定。为了帮助你决定是否给你的应用程序采用多个用户界面，你应该问自己这样几个问题。
第一，用户不在办公室时需要访问你的应用程序吗？对远程用户的支持是提供多个界面的主要原因。在许多情况下，这些用户确实需要一个单独的界面来运用应用程序。用户在一个拥挤的飞机场和在一个安静的办公室所使用的环境是完全不同的。
第二，你的应用程序需要在不同的平台上运行吗？因为.NET目前不提供跨平台的互用性，所以如果你的需求包括在非Windows操作系统上运行应用程序，那么你就应该创建一个ASP.NET应用程序，使用户可以从多个Web浏览器访问它（见工具条“.NET正走向成功”）。如果你运用Microsoft Mobile Internet Toolkit，所支持的Web浏览器可以包括那些在Palm OS PDAs和手机上运行的浏览器。
最后，你有需求截然不同的用户群吗？在着手开发应用程序前，仔细考虑这些问题是很值得的，否则会造成相当大的麻烦并给应用程序带来风险。只有当你确信你的应用程序用户的确需要多个界面时，你才可以投资来构建它们。
选择你的技术
一旦你决定构建一个具有多个界面的应用程序，你就需要确定运用哪种技术。.NET提供了许多用户界面选项，要对创建一个具有多个界面的.NET应用程序作出合理的选择，你就必须充分了解.NET相关的界面技术。
Windows Forms是在.NET中开发富客户端（rich client）应用程序的基础。客户端应用程序比其相应的基于浏览器的应用程序有一些固有的优势。用户可以运用客户端应用程序，而不需要网络连接。虽然在办公环境中网络已经无处不在了（尤其是随着诸如802.11这样的无线网络技术的普及），但在不能利用网络连接的情况下，用户仍需要很多应用程序。例如，他们可能需要在家运用一个应用程序，在这种情况下，只有很少数的用户有宽带连接；或者需要在车间运用应用程序，这时候由于电磁干扰而不能进行网络连接；或者在乘飞机旅行时。除了提供离线功能外，客户端应用程序也可以充分利用Windows的特殊功能，而基于浏览器的应用程序只能运用Windows“最低标准”的功能。
Windows Forms是Microsoft Foundation Classes（MFC）的“指定继承人”，它是Win32 API用户界面库的首选对象封装器（object wrapper），但是MFC和Windows Forms之间有许多不同。严格地说，MFC是个C++类的模式，而任何.NET语言都可以访问Windows Forms的类。另外，类的模式的灵活性和可用性都有了很多改进。由于MFC本质上是Win32上的一个thin wrapper，所以它有很多不一致性，而且很难学习并有效运用。Windows Forms类的模式是经过了改进的，一致的，它的学习曲线类似于Visual Basic的学习曲线，而且有更多的功能。运用Windows Forms，我们可以完成任何通过直接写到Win32类库来完成的任务。如果你需要扩展类来支持你的应用程序的一个特殊的用户界面，你可以通过继承Windows Forms的类来实现。
运用MFC或Visual Basic创建客户端应用程序的一个最大的缺点就是发布应用程序和所有必需的DLLs很困难。客户端应用程序的安装步骤通常很复杂，而且可能很麻烦。Windows Forms的智能客户端使我们可以在开发应用程序时将富客户端的强大性和灵活性与基于浏览器的应用程序容易发布的特点结合起来。
ASP.NET是在.NET中创建基于Web的应用程序的重要技术。近几年来，基于Web的应用程序已经超越了简单的数据库存取前端系统的范围，它包括许多不同的应用。基于Web的应用程序对客户端的限制非常低，这就是它们很受欢迎的一个原因。任何可以通过网络访问Web服务器的机器都可以运用一个将符合标准的HTML发送到浏览器的应用程序。在界面功能上你需要考虑这种功能，使用户可以在任何Web浏览器上访问一个应用程序，但是对于许多应用程序来说，固有的HTML标签提供的基本的用户界面部件就足够创建一个可用的界面了。
除了可以创建基于HTML的应用程序外，ASP.NET也使创建基于SOAP（Simple Object Access Protocol）的Web services变得非常容易了。在一个客户端应用程序中使用一个Web services也很简单。因为通过运用.NET的SOAP可以很容易地创建客户端/服务器应用程序，所以在你的应用程序中提供多个界面就变得更容易了。将Web services同富客户端结合起来就可以让用户享有Web应用程序和富客户端的好处，从而弥补了它们各自的不足。
你在考虑PDA用户界面时会有新的想法。虽然对PDAs的大肆宣传已经减少了，但它们仍代表了用户访问社团信息的一种方式。Gartner Dataquest预言在2002年会生产1550万PDAs。由于PDA的屏幕更小、输入技术有限以及典型的使用环境，所以对PDA界面的需求同对一个Windows或Web应用程序的需求有很大的不同。
因为为PDA设计可用的应用程序与Windows或Web应用程序的开发截然不同，所以.NET提供了工具以简化该步骤。Visual Studio .NET的Smart Device Extensions可以让开发人员运用.NET 工具（他们已经很熟悉了）来创建.NET Compact Framework应用程序。.NET Compact Framework是.NET Framework的一个子集，它在资源受到限制的（resource-constrained）设备上运行，如Pocket PC PDAs、智能电话和其它运行Windows CE .NET的设备。
.NET Compact Framework提供了必要的工具来创建可用的应用程序，包括客户端对Web services的访问、ADO.NET、加密、适当的绘图和窗体功能。除了只在Pocket PC设备上运行的.NET Compact Framework外，.NET也具有Microsoft Mobile Internet Toolkit（MIT）的特点。这个ASP.NET的扩展功能可以让开发人员在各种设备上创建Web应用程序，包括支持WAP的手机和大多数运行Palm OS的PDAs。它包含一组服务器端的控件，为列表、命令、通话、日历等提供用户界面元素。控件根据访问设备自动提供适当的标识语言（HTML、WML、cHTML）。这就可以让你把精力集中到应用程序逻辑的开发和用户回馈上，而MIT则负责无线开发的细节。
付诸实施
.NET提供了许多用户界面技术。为了有助于你了解如何运用它们，我们创建了一个样例应用程序，它有两个界面：一个Windows Forms客户端和一个ASP.NET客户端。样例是个时间跟踪和项目管理应用程序，是为一个专门的服务公司开发的，用来跟踪客户项目所花的时间。该应用程序有明显的需求不同的用户群，可以很好地说明多用户界面的应用。
在定义时间跟踪应用程序的根本的需求时，我们确定了四种不同的用户群：项目经理、顾问经理、顾问和订约人。前两种用户需要数据输入和报表分析的功能，而后两种用户只需要数据输入和远程访问功能。因为这些用户群的需求不同，所以我们把应用程序分成两个界面：一个用于管理和分析的Windows Forms应用程序，和一个用于数据输入和远程访问的ASP.NET Web Forms应用程序。
花时间了解应用程序的不同用户群的需求是很有价值的，而这个步骤经常被人们忽视（见工具条“建立可用性需求”）。在着手设计应用程序时了解用户群的需求可以使你的程序的重用性达到最大，还可以避免产品开发中的重复劳动。因为我们在设计应用程序时有了这样的了解，所以我们就可以用ASP.NET Web services了，并可以构建一个支持多个用户界面平台的简单而有效的应用程序。
集中的、跨平台的商业逻辑的一个危险就是在所有用户界面平台上实现该商业逻辑提供的全部功能。重要的一点是，我们应该关注个别界面的需求，不要因为可以得到某种商业逻辑提供的功能就去实现它。恰当的做法是要了解你的用户群并始终考虑他们的需求。
根据我们创建.NET应用程序的经验，我们已经掌握了一些有用的东西，在此我们将分享给你。软件开发中最大的挑战之一就是收集并记录需求。你努力去解决的问题（需求）往往会和那个问题的建议性解决方案（设计）混淆在一起。基本的用例可以帮你分辨需求和设计（见资源）。将基本用例与具体用例进行比较，你会发现具体用例中说明了用户和一个特殊界面之间的实际交互。当你编写一个具体用例时，你已经创建了（至少是含蓄地）用户界面。这种不成熟的界面设计可能在以后的开发周期中造成许多问题，尤其是如果你在你的应用程序中用了多个界面的话。如果用例指定了一个具体的依赖于特殊的Windows控件的交互层，那么当交互媒介发生改变时，你就必须修改需求。这就会导致需求的脆弱性，它会阻止正常的设计进程并延迟开发。
仔细设计商业逻辑
在确定需求时，除了要非常注意细节外，我们发现仔细设计商业逻辑层尤为重要。最重要的是，如果你打算运用Web services，你就需要注意管理串行化和传送域对象的媒介的局限性。设计和构建适当的Web services是该问题的关键：这个问题解决得好就可以让你在.NET中更容易地运用多个界面。虽然Web services伴随有许多夸张的宣传，但在多个界面设计方面，它们的灵活性确实是不可比拟的。
你也需要了解你的应用程序将呈现的界面的相关的技术细节。例如，客户端技术如何处理状态？虽然ASP.NET为Web应用程序简化了状态处理，但如果你的应用程序将有一个Web界面时，这仍然是个需要考虑的问题。因为Web依赖于无状态的HTTP协议进行通讯，因此确定如何跟踪一个用户在应用程序的位置这一负担就落在了应用程序开发人员的身上。在ASP.NET中跟踪状态比用以前的技术跟踪状态要容易很多，但你仍需要确定在你的应用程序中如何跟踪并运用状态信息。在设计应用程序时考虑其它问题（包括数据结构和持久性）也是很重要的。HTTP本身不支持传送和保持数据结构（同保持状态的问题类似），所以你必须确定如何在你的应用程序中实现它们。幸运的是，ASP.NET的易于使用的SOAP实现方式可以帮你解决这个问题。
忽视可用性是你在多界面应用程序中可能犯的最大的一个错误。对功能加以限定是种很好的方法：越少越好。在一个界面载入过多的功能会变得很混乱，而且很难使用。如果你遵循Bauhaus的设计格言――形式追随功能，那么就会得到更好的结果。了解你的应用程序可以提供的功能以及用户如何使用那些功能对于创建一个可用的应用程序来说是很必要的。这可能意味着，每个平台的界面根据那类用户期望的功能的不同而有很大的不同。
在样例应用程序中，Web和Windows Forms界面明显不同，因为我们有不同的用户群，他们的使用模式不同。运用该应用程序的顾问对创建漂亮的报表不感兴趣；他们只想根据项目记录时间。给他们提供“额外”的报表分析功能可能是个好主意，但是最小限度地增加复杂性都会造成应用程序总成本的增加。如果顾问们需要额外的报表功能，那么我们应该一步步地收集需求并构建该功能。
先测试最重要的UI
有时侯你可能不需要多个界面，你可以通过先测试最重要的界面来确定这一点。例如，如果应用程序的主要用户是内部Windows桌面用户，你可能认为智能客户端界面是最重要的。另一方面，如果主要用户是一群移动用户，你可能选.NET Compact Framework界面。不管你选择哪个界面，你应该首先创建这个最重要的界面，对它进行测试来看看你是否真的需要提供另外的界面。这就可以让你有机会仔细关注应用程序商业逻辑，并确信它是否非常稳固。通过一些可用性测试，你可能发现Web界面“需求”是不需要的，如果你有一个设计良好的Windows Forms智能客户端应用程序的话。如果测试表明你需要多个界面，你可以从最先发布的界面收集用户反馈，它们可以用来改进未来界面的设计。
.NET Framework提供了很多技术可以使创建多个用户界面的工作变得简单。然而，在创建有效的用户界面方面并没有什么“尚方宝剑”。不管你用什么工具，仍然会有可用性这个基本问题：需要对用户群及其用户有所了解。一旦你了解了这些，你的开发小组就需要设计一个用户界面使用户可以更有效地执行他们的任务了。最后，开发小组需要测试这个用户界面，确信它确实是个有效的解决方案。
多个用户群对一个应用程序的界面需求会截然不同，这种情况会越来越多，你可以利用.NET工具来创建你需要的界面。Windows Forms为Windows用户提供强大的、智能客户端功能，而ASP.NET可以使开发人员创建强大的Web应用程序；.NET Compact Framework和MIT可以让你创建灵活的PDA和手机用户界面。了解你可以运用的工具以及用户的需求是用.NET构建成功的用户界面的关键。
关于作者:Robert Ericsson是位经验丰富的软件开发人员和项目经理，他主要致力于Microsoft技术的研究。Jason Cline是位软件工程师，专门从事.NET Framework的研究。你可以通过dotnet@l10systems.com联系他们。
提前设计应用程序，使其满足用户对不只一个界面的需求。
by Robert Ericsson and Jason Cline
涉及技术：.NET Framework, ASP.NET, Windows Froms, .NET Compact Framework, Mobile Internet Toolkit
下载本文代码(http://www.fawcette.com/China/DotNetMagazine/2002_12/code/nm0212re.zip)
对于你们开发小组开发的软件，你可能想给用户提供最佳的用户界面，这就意味着你需要不只一个界面。用户希望可以在任何时候、任何地点、在各种设备上访问信息。这就形成了人们对灵活界面的需求，而且使应用程序的基本原理和用户界面的设计和创建显得更为重要了。在本篇文章中，我们将讲述一些用来定义、设计、构建和测试支持.NET多个用户界面的应用程序的最好的方法。我们的探讨只局限于现有的以及很快会实现的用于.NET平台的开发技术。然而，如果你们的开发团队已经创建了一个Java前端系统，并通过.NET Web services来运行一个服务器端应用程序的话，这些方法也同样适用。
在Rob Ericsson的“为好的UI 选择合适的工具”(http://www.fawcette.com/China/XmlFile.aspx?ID=25)一文中，他讲述了应用程序的一些特点，可以帮你选择是用Windows Forms还是用ASP.NET来实现一个应用程序。这种选择的要点就是要对每种技术进行成本效益分析，将应用程序的可用性作为一个最重要的因素来考虑。然而，这通常并不是一个简单的二选一的问题。有时侯，一个应用程序有很多不同的用户群。所以，用户的需求以及他们对用户界面的需求会有很大的差别就不足为奇了。对于这种类型的应用程序，“一刀切”（one-size-fits-all）式的Windows Forms或ASP.NET实现方式可能就不太适合了。
在这种情况下，你应该考虑创建一个可以提供多个用户界面的应用程序。对于这种具有多个界面的应用程序，我们可以将Microsoft Exchange Server作为例子来讲述：Outlook是Windows客户端，Outlook Web Access （OWA）是基于Web的界面。你临时不在办公室时使用OWA是很理想的，而Outlook Windows客户端是设计用于大量的日常工作的。然而，不同的界面并没有必要用不同的技术来构建。让我们来看一个客户服务中心的应用程序。客户服务电话接线员运用的数据录入界面同用来管理应用程序的界面有很大的不同，虽然它们都是用Windows Forms构建的。实际上，运用相同的界面技术来创建两个不同的界面比将多个界面技术整合到一个应用程序中要简单得多。
认可困难
虽然一些工具供应商认为创建具有多个用户界面的应用程序很简单，但事实并非如此。很多时候，创建一个Web或PDA应用程序所带来的兴奋感都会让开发人员失去理智，从而不去考虑Windows应用程序是否对用户更有效。另外添加一个界面会给你的应用程序带来许多复杂的问题，所以不要轻易作出这样的决定。为了帮助你决定是否给你的应用程序采用多个用户界面，你应该问自己这样几个问题。
第一，用户不在办公室时需要访问你的应用程序吗？对远程用户的支持是提供多个界面的主要原因。在许多情况下，这些用户确实需要一个单独的界面来运用应用程序。用户在一个拥挤的飞机场和在一个安静的办公室所使用的环境是完全不同的。
第二，你的应用程序需要在不同的平台上运行吗？因为.NET目前不提供跨平台的互用性，所以如果你的需求包括在非Windows操作系统上运行应用程序，那么你就应该创建一个ASP.NET应用程序，使用户可以从多个Web浏览器访问它（见工具条“.NET正走向成功”）。如果你运用Microsoft Mobile Internet Toolkit，所支持的Web浏览器可以包括那些在Palm OS PDAs和手机上运行的浏览器。
最后，你有需求截然不同的用户群吗？在着手开发应用程序前，仔细考虑这些问题是很值得的，否则会造成相当大的麻烦并给应用程序带来风险。只有当你确信你的应用程序用户的确需要多个界面时，你才可以投资来构建它们。
选择你的技术
一旦你决定构建一个具有多个界面的应用程序，你就需要确定运用哪种技术。.NET提供了许多用户界面选项，要对创建一个具有多个界面的.NET应用程序作出合理的选择，你就必须充分了解.NET相关的界面技术。
Windows Forms是在.NET中开发富客户端（rich client）应用程序的基础。客户端应用程序比其相应的基于浏览器的应用程序有一些固有的优势。用户可以运用客户端应用程序，而不需要网络连接。虽然在办公环境中网络已经无处不在了（尤其是随着诸如802.11这样的无线网络技术的普及），但在不能利用网络连接的情况下，用户仍需要很多应用程序。例如，他们可能需要在家运用一个应用程序，在这种情况下，只有很少数的用户有宽带连接；或者需要在车间运用应用程序，这时候由于电磁干扰而不能进行网络连接；或者在乘飞机旅行时。除了提供离线功能外，客户端应用程序也可以充分利用Windows的特殊功能，而基于浏览器的应用程序只能运用Windows“最低标准”的功能。
Windows Forms是Microsoft Foundation Classes（MFC）的“指定继承人”，它是Win32 API用户界面库的首选对象封装器（object wrapper），但是MFC和Windows Forms之间有许多不同。严格地说，MFC是个C++类的模式，而任何.NET语言都可以访问Windows Forms的类。另外，类的模式的灵活性和可用性都有了很多改进。由于MFC本质上是Win32上的一个thin wrapper，所以它有很多不一致性，而且很难学习并有效运用。Windows Forms类的模式是经过了改进的，一致的，它的学习曲线类似于Visual Basic的学习曲线，而且有更多的功能。运用Windows Forms，我们可以完成任何通过直接写到Win32类库来完成的任务。如果你需要扩展类来支持你的应用程序的一个特殊的用户界面，你可以通过继承Windows Forms的类来实现。
运用MFC或Visual Basic创建客户端应用程序的一个最大的缺点就是发布应用程序和所有必需的DLLs很困难。客户端应用程序的安装步骤通常很复杂，而且可能很麻烦。Windows Forms的智能客户端使我们可以在开发应用程序时将富客户端的强大性和灵活性与基于浏览器的应用程序容易发布的特点结合起来。
ASP.NET是在.NET中创建基于Web的应用程序的重要技术。近几年来，基于Web的应用程序已经超越了简单的数据库存取前端系统的范围，它包括许多不同的应用。基于Web的应用程序对客户端的限制非常低，这就是它们很受欢迎的一个原因。任何可以通过网络访问Web服务器的机器都可以运用一个将符合标准的HTML发送到浏览器的应用程序。在界面功能上你需要考虑这种功能，使用户可以在任何Web浏览器上访问一个应用程序，但是对于许多应用程序来说，固有的HTML标签提供的基本的用户界面部件就足够创建一个可用的界面了。
除了可以创建基于HTML的应用程序外，ASP.NET也使创建基于SOAP（Simple Object Access Protocol）的Web services变得非常容易了。在一个客户端应用程序中使用一个Web services也很简单。因为通过运用.NET的SOAP可以很容易地创建客户端/服务器应用程序，所以在你的应用程序中提供多个界面就变得更容易了。将Web services同富客户端结合起来就可以让用户享有Web应用程序和富客户端的好处，从而弥补了它们各自的不足。
你在考虑PDA用户界面时会有新的想法。虽然对PDAs的大肆宣传已经减少了，但它们仍代表了用户访问社团信息的一种方式。Gartner Dataquest预言在2002年会生产1550万PDAs。由于PDA的屏幕更小、输入技术有限以及典型的使用环境，所以对PDA界面的需求同对一个Windows或Web应用程序的需求有很大的不同。
因为为PDA设计可用的应用程序与Windows或Web应用程序的开发截然不同，所以.NET提供了工具以简化该步骤。Visual Studio .NET的Smart Device Extensions可以让开发人员运用.NET 工具（他们已经很熟悉了）来创建.NET Compact Framework应用程序。.NET Compact Framework是.NET Framework的一个子集，它在资源受到限制的（resource-constrained）设备上运行，如Pocket PC PDAs、智能电话和其它运行Windows CE .NET的设备。
.NET Compact Framework提供了必要的工具来创建可用的应用程序，包括客户端对Web services的访问、ADO.NET、加密、适当的绘图和窗体功能。除了只在Pocket PC设备上运行的.NET Compact Framework外，.NET也具有Microsoft Mobile Internet Toolkit（MIT）的特点。这个ASP.NET的扩展功能可以让开发人员在各种设备上创建Web应用程序，包括支持WAP的手机和大多数运行Palm OS的PDAs。它包含一组服务器端的控件，为列表、命令、通话、日历等提供用户界面元素。控件根据访问设备自动提供适当的标识语言（HTML、WML、cHTML）。这就可以让你把精力集中到应用程序逻辑的开发和用户回馈上，而MIT则负责无线开发的细节。
付诸实施
.NET提供了许多用户界面技术。为了有助于你了解如何运用它们，我们创建了一个样例应用程序，它有两个界面：一个Windows Forms客户端和一个ASP.NET客户端。样例是个时间跟踪和项目管理应用程序，是为一个专门的服务公司开发的，用来跟踪客户项目所花的时间。该应用程序有明显的需求不同的用户群，可以很好地说明多用户界面的应用。
在定义时间跟踪应用程序的根本的需求时，我们确定了四种不同的用户群：项目经理、顾问经理、顾问和订约人。前两种用户需要数据输入和报表分析的功能，而后两种用户只需要数据输入和远程访问功能。因为这些用户群的需求不同，所以我们把应用程序分成两个界面：一个用于管理和分析的Windows Forms应用程序，和一个用于数据输入和远程访问的ASP.NET Web Forms应用程序。
花时间了解应用程序的不同用户群的需求是很有价值的，而这个步骤经常被人们忽视（见工具条“建立可用性需求”）。在着手设计应用程序时了解用户群的需求可以使你的程序的重用性达到最大，还可以避免产品开发中的重复劳动。因为我们在设计应用程序时有了这样的了解，所以我们就可以用ASP.NET Web services了，并可以构建一个支持多个用户界面平台的简单而有效的应用程序。
集中的、跨平台的商业逻辑的一个危险就是在所有用户界面平台上实现该商业逻辑提供的全部功能。重要的一点是，我们应该关注个别界面的需求，不要因为可以得到某种商业逻辑提供的功能就去实现它。恰当的做法是要了解你的用户群并始终考虑他们的需求。
根据我们创建.NET应用程序的经验，我们已经掌握了一些有用的东西，在此我们将分享给你。软件开发中最大的挑战之一就是收集并记录需求。你努力去解决的问题（需求）往往会和那个问题的建议性解决方案（设计）混淆在一起。基本的用例可以帮你分辨需求和设计（见资源）。将基本用例与具体用例进行比较，你会发现具体用例中说明了用户和一个特殊界面之间的实际交互。当你编写一个具体用例时，你已经创建了（至少是含蓄地）用户界面。这种不成熟的界面设计可能在以后的开发周期中造成许多问题，尤其是如果你在你的应用程序中用了多个界面的话。如果用例指定了一个具体的依赖于特殊的Windows控件的交互层，那么当交互媒介发生改变时，你就必须修改需求。这就会导致需求的脆弱性，它会阻止正常的设计进程并延迟开发。
仔细设计商业逻辑
在确定需求时，除了要非常注意细节外，我们发现仔细设计商业逻辑层尤为重要。最重要的是，如果你打算运用Web services，你就需要注意管理串行化和传送域对象的媒介的局限性。设计和构建适当的Web services是该问题的关键：这个问题解决得好就可以让你在.NET中更容易地运用多个界面。虽然Web services伴随有许多夸张的宣传，但在多个界面设计方面，它们的灵活性确实是不可比拟的。
你也需要了解你的应用程序将呈现的界面的相关的技术细节。例如，客户端技术如何处理状态？虽然ASP.NET为Web应用程序简化了状态处理，但如果你的应用程序将有一个Web界面时，这仍然是个需要考虑的问题。因为Web依赖于无状态的HTTP协议进行通讯，因此确定如何跟踪一个用户在应用程序的位置这一负担就落在了应用程序开发人员的身上。在ASP.NET中跟踪状态比用以前的技术跟踪状态要容易很多，但你仍需要确定在你的应用程序中如何跟踪并运用状态信息。在设计应用程序时考虑其它问题（包括数据结构和持久性）也是很重要的。HTTP本身不支持传送和保持数据结构（同保持状态的问题类似），所以你必须确定如何在你的应用程序中实现它们。幸运的是，ASP.NET的易于使用的SOAP实现方式可以帮你解决这个问题。
忽视可用性是你在多界面应用程序中可能犯的最大的一个错误。对功能加以限定是种很好的方法：越少越好。在一个界面载入过多的功能会变得很混乱，而且很难使用。如果你遵循Bauhaus的设计格言――形式追随功能，那么就会得到更好的结果。了解你的应用程序可以提供的功能以及用户如何使用那些功能对于创建一个可用的应用程序来说是很必要的。这可能意味着，每个平台的界面根据那类用户期望的功能的不同而有很大的不同。
在样例应用程序中，Web和Windows Forms界面明显不同，因为我们有不同的用户群，他们的使用模式不同。运用该应用程序的顾问对创建漂亮的报表不感兴趣；他们只想根据项目记录时间。给他们提供“额外”的报表分析功能可能是个好主意，但是最小限度地增加复杂性都会造成应用程序总成本的增加。如果顾问们需要额外的报表功能，那么我们应该一步步地收集需求并构建该功能。
先测试最重要的UI
有时侯你可能不需要多个界面，你可以通过先测试最重要的界面来确定这一点。例如，如果应用程序的主要用户是内部Windows桌面用户，你可能认为智能客户端界面是最重要的。另一方面，如果主要用户是一群移动用户，你可能选.NET Compact Framework界面。不管你选择哪个界面，你应该首先创建这个最重要的界面，对它进行测试来看看你是否真的需要提供另外的界面。这就可以让你有机会仔细关注应用程序商业逻辑，并确信它是否非常稳固。通过一些可用性测试，你可能发现Web界面“需求”是不需要的，如果你有一个设计良好的Windows Forms智能客户端应用程序的话。如果测试表明你需要多个界面，你可以从最先发布的界面收集用户反馈，它们可以用来改进未来界面的设计。
.NET Framework提供了很多技术可以使创建多个用户界面的工作变得简单。然而，在创建有效的用户界面方面并没有什么“尚方宝剑”。不管你用什么工具，仍然会有可用性这个基本问题：需要对用户群及其用户有所了解。一旦你了解了这些，你的开发小组就需要设计一个用户界面使用户可以更有效地执行他们的任务了。最后，开发小组需要测试这个用户界面，确信它确实是个有效的解决方案。
多个用户群对一个应用程序的界面需求会截然不同，这种情况会越来越多，你可以利用.NET工具来创建你需要的界面。Windows Forms为Windows用户提供强大的、智能客户端功能，而ASP.NET可以使开发人员创建强大的Web应用程序；.NET Compact Framework和MIT可以让你创建灵活的PDA和手机用户界面。了解你可以运用的工具以及用户的需求是用.NET构建成功的用户界面的关键。
关于作者:Robert Ericsson是位经验丰富的软件开发人员和项目经理，他主要致力于Microsoft技术的研究。Jason Cline是位软件工程师，专门从事.NET Framework的研究。你可以通过dotnet@l10systems.com联系他们。
