微软提供一套完整的产品让其他公司去开发和部署n层应用程序。在从C/S或者Internet应用程序转移到逻辑n层应用程序的过程中我们缺少的是一些指导，比如说每一层应该完成一些什么功能，每一层如何组合起来形成一个具有可重用部分的紧凑应用程序。
为了带领你完成这样一个转移，我已经详细的划分了每一层的核心组件的功能。在讨论这些组件的过程中，我将会给出一些有关开发三层应用程序的基本建议。
表示层
多数开发者认为表示层仅仅是一些收集信息和检查信息合法性的Web表单或者Windows窗体。但是创建具有用户界面（UI）过程和状态管理功能的单片电路窗体也要求你为每一个潜在的客户设备复制这些功能。为了提高可重用性、减少代码重复，表示层应该分解为两类组件。
第一个组件是用户界面，应该包括处理接收到的信息并显示从商业层提取的信息的窗体。但是说明一个处理过程（订单或者发票处理）状态的信息应该维持在一个单独的用户处理（UP）组件。UP组件能驱动并管理用具户处理过程，不管它是从一个Web客户端、Windows客户端还是设备发起的。
商业层
商业层的组件接受从UP组件发出的请求。根据制定好的规则，请求被翻译为由已定义的工作流控制的动作。他们也负责与外部系统的接口，通知UP组件有一个统一的层，从该层中UP组件可以使用一组标准的服务。商业层的这项功能可以分解为三类关键组件：商业工作流（BW）、商业规则（BR）以及服务代理（SA）。
BW组件管理完成一个商业事务所需的一系列事件。这些事件可能发生在一小段时间内，也有可能需要一段很长的时间。商业服务管道（CSP）就是BW组件的一个例子。CSP通过UP组件完成订单篮的管理，然后完成其他一些步骤的处理，包括信用卡检查、运送管理以及抽税等。当所有的这些已经完成之后，它会返回一个订单ID给UP组件以供UI组件来显示。长期事务可以由Windows服务管理，这些服务监视队列或者数据库表，并响应驱动工作流事件引起的变化。长期事务还可以由具有完成相似功能的复杂配合引擎的服务器来完成，例如BizTalk等。
BW组件管理处理过程，但它们使用BR组件去增强规则或者完成特定任务。如果开发合理正确，不同应用程序中的不同的BW组件可使用相同的BR组件。
很多时候，应用程序要求的功能在其他的企业或者合作伙伴的系统中已经实现。与其做重复的努力，你可以选择在商业层中使用它们的服务。为了使你的所有组件接口一致，你应该开发出一组可以使用外部服务以及创建通用外观的SA。这样的话，无论外部服务是一个Web service、大型机的CICS会话，甚至是一个EJB组件，其内部表示都是一致的.NET组件接口。
数据层
虽然数据访问组件的实现相当简单，但如何恰当地使用它们一直都是一个争论的焦点。一方面，DBA认为所有的商业规则都应该存在于存储过程和触发器中。另一方面，开发者则认为数据库唯一的功能应该是优化数据访问。
作为一个系统架构工程师，我站在开发者那一边。我已经看到太多的系统随着时间的推移其性能有很大的损失，以至于很难管理，原因就是服务器由于要处理商业规则过程变得速度非常的慢。多数n层分析家现在一致认为DA组件应该简化为只向BR组件提供创建、读取、更新以及删除（CRUD）功能以及参与他们自身引发的事务处理。
另外一个在设计n层系统时需要考虑的关键因素是如何在层间传递数据。商业实体（BE）组件封装了所有的需要在层间传递的数据，也可能还包含数据合法性检查（处理数据集或者对象的情况）。使用哪种类型的BE来传递数据是最初设计系统时最重要的决定。
鉴于微软提供了一套新的工具，创建组成系统的组件比以往容易了很多。但是你依然需要花时间去设计每个组件以及在这些组件中传递BE的方法。
