Windows桌面用户界面
当你必须提供不连线，或者脱机能力，或者提供丰富的用户交互，或者提供和其它应用程序集成时，Windows用户界面就有被使用的价值。Windows用户界面可以发挥它更广泛的优势，这些优势包括状态管理，持续选择和访问本地进程的能力。有三个主要的独立的用户界面家族：“填充式（full—blown）”基于Windows的应用程序，包括内嵌HTML的基于Windows的应用程序，和可以用于宿主应用程序界面的应用程序插件。
l 使用Windows Form构建的“填充式（full—blown）”桌面/tablet PC用户界面
构建一个基于Windows的应用程序，这个应用程序包括使用Windows Forms和应用程序提供的控件，这些控件全部或者大部分具有数据展现的功能。这些赋予你在用户体验方面的大量可控性和应用程序外观上全部控制。然而，它依赖于客户端平台，而且应用程序需要被部署到用户端（即使应用程序通过HTTP链接下载部署）。
l 内嵌的HTML
你可以选择全部使用Windows form实现用户界面，另外，也可以在你基于Windows的应用程序中内嵌HTML。内嵌的HTML体现了更好的运行时的灵活性（因为HTML可以从外部资源，甚至在链接的情况下从数据库中加载）和用户可自定义。然而，你需要谨慎考虑如何防止恶意的脚本被导入到HTML中，需要另外的代码加载HTML和显示它，并使用你的应用程序功能勾住控件的事件。
l 应用程序插件
你的许多应用场景建议，你的应用程序的用户界面作为另一个应用程序的插件，可能会更好，诸如，作为Microsoft Office，AutoCAD, CRM解决方案，工程学工具，等等。在这个情况下，你可以获得宿主应用程序的所有数据采集器和显示逻辑的优势，仅关注提供代码来采集数据和你的业务逻辑。
许多近代的应用程序都为COM和DotNET提高插件的特定接口。或者作为内嵌的开发环境（比如，Microsoft Visual Basic开发系统，非常广泛地支持基于Windows的许多通用的应用程序），因此可以调用自定义对象。有些内嵌环境（包括Visual Basic）甚至提供窗体引擎，赋予你增加用户界面经验的能力，可以超越宿主应用程序提供能力。有关在宿主应用程序中使用Visual Basic的更多信息，见MSDN上的“Microsoft Visual Basic for Application and Windows DNA 2000” (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndna/html/vba4dna.asp).
有关工作在Microsoft Office上的DotNET的信息，见MSDN上的“Microsoft Office and DotNET Interoperability” (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnofftalk/html/office11012001.asp).
当创建一个基于Windows Form的应用程序时，考虑以下建议：
l 依赖数据绑定使同时打开的多个窗体保持数据的同步。这个可以减轻写复杂的代码使数据同步。
l 在窗体之间避免硬编码它们的关系，依赖用户处理组件来打开它们和同步数据及事件。特别要注意，避免硬编码处理从子窗体到父窗体的关系。例如，一个产品明细窗体可能被应用程序的其它地方重用，不仅是来源于一个订单输入窗体，所以，你应该避免在产品明细的窗体中仅实现直接链接到订单输入窗体的功能实现。这会是你的用户界面增加更多的可重用性。
l 在你的窗体中实现错误处理。如果你没有在别处处理异常，这样做，可以防止看到不友好的DotNET异常窗体，造成应用程序失败。所有的事件处理和控制器功能要包括异常捕获。另外，你应该为你的用户界面创建一个自定义的异常类，包含简要说明失败操作是否可以被重试或者取消的元数据。
l 在用户界面中验证用户的输入。验证发生在用户的任务或者处理阶段允许验证的及时点（point-in-time）上（允许用户敲入一些必需的数据，继续一个单独的任务，然后，返回到当前任务）。在有些情况下，你要做些暗示性的方法，使控件无效，视觉上暗示用户无效数据被录入了。在用户界面验证用户的输入，可以在输入无效数据时，防止服务边界之间不必要的往返调用。
l 如果你创建自定义控件，你仅需要暴露你实际需要的公开属性和方法。这会使组件更容易维护。
l 你实现的控制器功能会和你的客户端一起被部署，但要和你所在的Windows Form或者DotNET类进行隔离。不在控件事件处理中直接实现控制器的功能。在事件处理中写控制逻辑，会减弱应用程序的可维护性，因为你可能在将来其它事件中调用相同的功能。例如，在一个名字叫addItem命令按钮的单击事件中调用常规的程序完成它的任务，代码如下。
l private void addItem_Click(object sender, System.EventArgs e)
l {
l AddItemToBasket(selectedProduct, selectedQuantity)
l }
l public void AddItemToBasket(int ProductID, int Quantity)
l {
l // code to add the item to the basket
l }
Internet浏览器用户界面
在这个指南中描述的零售应用程序需要一个基于WEB的用户界面，允许客户通过Internet提交订单。基于Web的用户界面允许基于标准的用户界面横穿在许多设备和平台上。你可以使用ASP.NET开发基于DotNET应用程序的WEB用户界面。ASP.NET提供丰富的环境，使你可以创建复杂的WEB界面，它支持的重要特征有：
l 一致的开发环境，也可以创建其它应用程序使用的组件。
l 用户界面的数据绑定。
l 基于组件用户界面的控件化。
l 访问集成到DotNET的安全模式。
l 丰富的缓存和状态管理作为可选项。
l WEB处理的可用性，性能和可度量性。
当你需要实现一个浏览器应用程序时，ASP.NET提供了发布WEB页面用户界面的功能。ASP.NET用户界面的设计考虑如下建议：
l 实现一个自定义的错误页面，在Gloabal.asax中处理全局性的异常处理。这个给你提供捕获所有异常的功能，可以防止用户看到有问题的情况下的不友好页面。
l ASP.NET有一个丰富的验证框架，优化保证用户的输入是符合某些标准的作业。然而，客户端的验证执行，依赖于你在客户端写的浏览器支持的JavaScript，所以，在没有JavaScript支持的浏览器情况下（或者JavaScript被禁止），你最好在你的控制器功能中验证数据。如果你的用户过程有一个验证控制功能，在转换到其它页面之前调用它，执行及时点（point-in-time）的验证。
l 如果你创建了WEB用户控件，仅需要暴露你实际需要的公共属性和方法。这可以改善可维护性。
l 使用ASP.NET视图状态来存储页面特定的状态，持续会话（keep session），为数据扩大更广泛的范围，使用应用程序状态。这个方法更容易维护和改善可度量性。
l 你的控制器功能要调用一个用户处理组件的行为，通过当前任务来引导用户用户，而不是使用户直接改变页面。用户处理组件可能调用Redirect功能使服务器显示不同的页面。这样做，你必须为你的用户处理组件引用System.Web命名空间。（注意，这意味着你的用户处理组件不能被基于Windows的应用程序重用，所以，你要在不同的的类中实现Redirect的调用。）
l 你实现的控制器功能会和你的WEB页面一起被部署，但要和你所在的ASP.NET页面或者DotNET类进行隔离。在ASP.NET提供的事件处理里写业务逻辑会减弱站点的可维护性，因为你可能在未来的另一个事件中调用相同的功能。这样做，也会对只写UI代码部分开发人员要求更好的技能。
例如，假设零售WEB站点包含一个有命名按钮的页面，单击它可以增加一个产品到购物篮。ASP.NET控件的标志如下代码。
<asp:Button id="addItem" OnClick="addItem_Click"/>
正如你从这个代码可能看到的，按钮的OnClick时间是通过一个名称叫addItem_Click的功能处理。然而，事件的处理不包含执行行为的代码（在这个情况下，增加一项到购物篮），而是调用另外一个功能，如下面的代码所示。
private void addItem_Click(object sender, System.EventArgs e)
{
AddItemToBasket(selectedProduct, selectedQuantity)
}
public void AddItemToBasket(int ProductID, int Quantity)
{
// code to add the item to the basket
}
这个另外抽离的层保证，代码可能被多个用户界面元素重用，执行控制器的任务。更多有关ASP.NET的一般信息，见MSND上的ASP.NET章节(http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000440)，和官方的ASP.NET站点(http://asp.net)。
在许多应用程序中，重要的是，提供可扩展的框架，使多个面板根据不同的目的而被显示。在基于Web的应用程序中，你也需要提供一个首页或者引导用户界面，是和用户相关的任务和信息显示在敏感的上下文环境和图案上。微软提供一些资源帮助你实现基于WEB的门户：
l Microsoft Content Management Server (http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001368)。
l Microsoft SharePoint Portal™ Server 2001 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spssdk/html/_welcome_to_tahoe.asp)。
l IBuySpy Portal (http://msdn.microsoft.com/library/en-us/dnbda/html/bdasampibsport.asp)。
移动用户界面
移动设备如手持PC，WAP手机，iMode设备会日益流行，为移动因素构建用户界面提出它自身独特的考验（building user interface for a mobile form factor presents its own unique challenges）。
一般情况下，相对于其它应用程序，为移动设备构建用户界面需要能够在很小的屏幕上显示信息，必须把为设备提供可接受的实用性作为目标。因为，在许多移动设备上，用户的交互式是难使用的，特别是移动电话，你设计的移动用户界面需要用最少的数据输入。通用的策略是移动设备的使用采用全屏幕式的WEB或者Windows应用程序，允许用户预先通过桌面客户端装载数据，然后，当使用移动客户端时，再选择它。例如，一个电子商务应用程序可以允许用户通过WEB站点装载信用卡明细，当订单从移动设备上被提交时，方便从列表中选择已预装的信用卡（从而避免了使用移动电话的键或者PDA铁笔输入需要的信用卡的所有明细）。
Web用户界面
移动设备广泛地支持Internet浏览器。有些使用微浏览器支持HTML3.2的子集，有些需要数据被发送到WML，有些支持其它标准，如，Compact HTML（cHTML）。 你可以使用Microsoft Internet ToolKit创建基于ASP.NET的WEB应用程序，根据设备类型，你可发送请求头可以被识别的标志标准给对应的设备。如此，可以使你创建单个的WEB应用程序，使其适应不同的移动客户端，这些移动客户端包括Pocket PC，WAP电话，iMode电话，和其它。
和其它用户界面类型一样，在Web页面，你要把用户输入的无效数据减到最少。Mobile Internet Toolkit包括客户端边的验证控制，如，CompareValidator，CustomValidator, RegularExpressionValidator， 和 RequiredFieldValidator验证控制，这些验证控制可以用在多个客户端设备类型上。你也可以使用输入字段的属性（如，Textbox控件）来限制输入可接受的类型（例如，仅接受数字输入）。然而，你总会想到一些客户端设备不支持客户端边验证，数据提交到服务器后，在执行额外的检查。
有关Mobile Internet ToolKit的更多信息，见MSDN上的Microsoft Mobile Internet Toolkit 页面(http://msdn.microsoft.com/vstudio/device/mitdefault.asp)。
智能设备的用户界面
Pocket PC是一个基于Windows CE操作系统具有丰富特征的设备，在它上面，你可以开发断线和连线用户界面（通常通过无线）。Pocket PC平台包括手持PDA设备和智能手机，综合了PDA和手机的特征。
微软为Pocket PC和其它Windows CE平台提供了DotNET Compact Framework。这个框架包括了DotNET框架的子集，允许为移动设备开发基于DotNET的丰富的应用程序。开发者可以使用Visual Studio.NET为目标为DotNET Compact Framwork创建应用程序。（译注：这里省去了Visual Studio.NET的智能设备扩展，因为现在的Visual Studio.NET对智能设备的支持已经是完全集成，而不是一个扩展包。）
正如规范的基于Windows用户界面一样，当操作失败时，你要提供异常处理来告知用户，允许用户以合适的方法重试和取消它。
Microsoft Visual Studio.NET没有提供输入验证控制，所以，你需要自己实现验证，保证所有的输入时有效的。
有关Pocket PC平台和DoNET Compact Framework的开发资源，见MSDN上的Smart Device Extensions 页(http://msdn.microsoft.com/vstudio/device/smartdev.asp)。
你要考虑的另一个有丰富客户端移动因素的是Tablet PC。Tablet PC是基于Windows XP便携式设备，通过“墨迹（pen and ink）”和用户交互，这个“墨迹”隐喻了用户在屏幕上的“画”和“写”。自从Tablet PC基于Windows XP，DotNET Framework全部的优势都有效。另外增加的处理“墨迹”集成的API也是有效的。更多关于设计Tablet PC应用程序的信息，见MSDN上 Design Recommendations for Exploiting the Pocket PC (http://msdn.microsoft.com/library/en-us/tpcsdk10/html/whitepapers/designguide/tbconuxdgformfactorpenandink.asp)。
基于文档的用户界面
在有效情况下，比构建一个自定义基于Windows的桌面应用程序对推进用户容易交互更有意义的是， 允许用户在公共的产品工具中集成系统，这些公共的产品工具如Microsoft Word，或者Microsoft Excel。文档一般比喻为和数据结合在一起的工作。在一些应用程序里，用户使用它们平常使用的文档工具进行输入或者浏览数据，对应用程序是有益的。
考虑下面基于文档的解决方案：
l 报告数据。你的应用程序（基于Windows或者基于WEB）可以提供一些特征给用户，让他或者她咋合适的文档类型中看数据----例如，在Word文档中显示发票数据，或者在Excel电子表格中显示价格列表。
l 采集数据。你可以使为通过电话和用户沟通的销售代表在Excel电子表格中输入订单信息，创建客户订单文档，然后提交文档给你的业务过程。
有两种方法在文档中综合你的用户体验，分解成两个一般的场景：从用户那里采集数据和报告数据给用户。
使用来源于外部的文档
你可以使用“来源于外部”的文档，把它们作为一个实体处理。在这样的场景下，你对一个文档的代码操作，不需要明白它的应用程序细节。在特定的会话之外，文档文件可以被保护起来，是这个方法的优势。这个模式可以提供给你这样的好处：你的应用程序不必要处理这个文档，而这个文档又需要被保护时，你可以在“任意”范围内处理它。例如，你选择了这个模式，允许用户在移动设备上输入信息，发挥Pocket PCActiveSync的能力，使移动设备上文档和保存在服务器上文档之间的数据同步。在这样的设计模式下，你的用户界面将会执行以下功能：
l 采集数据。一个用户在一个文档上输入信息，从一个空白文档开始，或者最典型的是，从一个指定的领域的预定义模板开始。
然后，用户提交这个文档到一个基于Windows的应用程序，或者上传到一个基于WEB的应用程序。使用文档对象模型，这个应用程序扫描文档的数据和区域，然后，执行必要的行为。
在这个点上，在对文档处理完后，你来决定是保存它，或者销毁它。典型处理方法是，文档被保存起来，来维护一个历史跟踪，或者在用户输入的那个地方保存一个副本数据。
l 报告数据。在这个情况下，一个基于Windows或者基于Web的用户界面提供一个方法，生一个显示数据的文档，比如，一个销售发票。通常下，报告数据的代码获取的数据来源于正在进行的用户过程，业务过程，数据访问逻辑组件，调用文档应用程序上的宏来注入数据并格式化它，或者使用一个当前正确的文件格式保存成一个文档，并把它返回给用户。你可以把文档保存到磁盘，提供一个链接返回给用户（你需要在安全的WEB领域中央存储区保存文档），或者把它作为返回的一部分。
当在一个基于WEB的应用程序中返回文档时，你要确定是否在浏览器中显示文档给用户浏览，或者使用选项提供给用户保存文档到磁盘。一般情况下，在返回的ASP.NET页面中，这个可以使用设置正确的MIME类型达到控制。在WEB环境下，你需要遵循文件命名约定小心防止并发用户重写其他人的文件。
使用来源于内部的文档
当你想在文档中提供综合的用户体验时，你可以使应用程序逻辑嵌入在文档里面。在这个设计模式下，你的用户界面执行以下的功能：
l 采集数据。在带有预定义的窗体的文档中，用户可以输入数据，然后，指定调用模板上的宏，采集正确的数据，调用你的业务或者用户处理组件。这个方法提供更多的综合的用户体验，因为，用户仅点击宿主应用程序的一个自定义按钮，或者菜单项，就执行需要的期望的工作，而不需要提交全部的文档。
l 报告数据。在你的文档中，你实现自定义菜单项和按钮，从服务器采集一些数据并显示它。你也可以选择在你的文档中使用智能标签，这些智能标签可以横穿所有Microsoft Office产品工具提供丰富的一条线集成功能。例如，你提供一些智能标签，当一个销售代表在文档上敲入一个客户的名字，智能标签就显示客户的全部联系信息，这些数据来源于CRM数据库。
无论你是使用来源于外部或者来源于内部的文档，你要提供一些验证逻辑保证用户的输入的所有数据是有效的。你可以通过限制字段的数据类型达到一部分目的，但在大多数情况下，你将需要实现自定义功能来检查用户的输入，和当无效数据被探测到时，显示错误消息。基于Microsoft Office的文档可以使用自定义宏来提供这样的功能。
有关如何纯粹地使用基于Office的UI集成你的业务处理的更多信息，见MSDN上的“Microsoft Office XP Resource Kit for BizTalk Server Version 2.0” (http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/743/msdncompositedoc.xml)。
有关Office和DotNET之间的使用的更多信息，见MSDN。下面的两个文章会帮你开始Office和DotNET的应用程序开发：
l “Introducing .NET to Office Developers” (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnofftalk/html/office10042001.asp)。
l “Microsoft Office and .NET Interoperability” (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnofftalk/html/office11012001.asp)。
通过发挥由Microsoft SharePoint Portal提供的服务优势，你可以管理基于文档的工作流。这个产品也可以处理用户处理，提供丰富的元数据，处理搜索的能力。
