• 应用需要支持平台无关性
• 多个应用程序的功能放进一个单一的界面来提供
• 采用请求-响应模式运行
• 需要开发软件加服务(Software plus service)，软件即服务(Software as a service)类型的应用，或者基于云计算的应用

那么我们可以选择面向服务的架构。

针对目前的场景：大型ASP.NET应用，那么它最基本的需求可能是这样的：

同时访问的用户将会是相当多的，比如几千个，上万个。

7x24小时都有大量用户访问

某些地方需要用户登录以获取一些需要授权才能获得的信息

我们可能选择的架构组合可能是这样的：

3Tier/N Tier的架构

Model, View, Controller(MVC)架构结合3Tier/N Tier的架构

3Tier/N Tier的架构结合面向服务的架构

3Tier/N Tier的架构结合面向对象的架构

当然也有可能是其他的组合。

　　分层Layered的架构不适合大型的ASP.NET应用。分层Layered的架构通常将UI层，商务逻辑，数据访问层都部署在同一台服务器上，首先一台服务器不能负担众多的用户，还有复杂的商务逻辑不是一台服务器能全部担负的。所以分层Layered的架构不适合大型的ASP.NET应用。小型的ASP.NET应用才适合分层Layered的架构。

　　基于组件的架构也不适合大型ASP.NET应用。通常来说大型的ASP.NET应用都是相当复杂的，它的UI界面，商务逻辑，数据都是复杂的。不会简单到调用几个控件就完成了大部分的工作，大型的ASP.NET应用的每一个Tier排，都需要众多的服务器来分担压力，基于组件的架构的分布式能力有限，所以基于组件的架构是通常不会在大型ASP.NET应用里考虑的，除非是有若干个重要的控件，并且要考虑集成多个编程语言的控件时，才会考虑基于组件的架构。而且是在某个局部使用，即需要与其他架构一起结合起来用。

　　消息总线型架构可以在某些场景下参与大型ASP.NET应用的开发。通常是需要将多个系统平台整合在一起的时候。消息总线型的架构需要结合其他的架构来共同构造ASP.NET应用。

　　MVC架构关注的更多的是UI，用户交互的控制以及数据存取的分离。通常不能单独去构造一个大型的ASP.NET架构。需要结合3Tier/N Tier架构来共同构造大型ASP.NET的架构。MVC架构在UI还有用户交互上有固定的模式，所以可以在UI这一块应用MVC的架构，当涉及到MVC中的模型Model时，就可以扩展到3 Tier/N Tier的架构。即在访问模型Model时，就去访问另外一个服务器上的商务逻辑和数据存储。这个可以用下图来表示：

　　面向对象的架构是更多地关注应用里面的面向对象分析，设计等过程产生出来的结果。这个结果体现了现实世界中的对象之间的交互作用。面向对象的架构需要结合其他架构如3 Tier/N Tier架构来共同构造ASP.NET应用程序的架构。

　　面向服务的架构是在特定场景下需要的。即上面所说的，多个功能作为一项服务，提供一个统一的UI给外界用户。大型ASP.NET应用中通常需要将商务逻辑提供给公众访问。这时就可以采用面向服务的架构。面向服务的架构也需结合其他架构如3 Tier/N Tier架构来共同构造ASP.NET应用程序的架构。

 　　3 Tier/N Tier架构对于大型ASP.NET应用来说是必须的。它的每一Tier排都由若干服务器组成。只有这样才可以服务众多的用户。如上面的图所示，UI调用商务逻辑时得跨越机器的边界，调用另外一台服务器上的商务逻辑服务接口。

结束语

　　架构的选择需要根据不同架构的特点和应用程序的需求来进行选择，有时候需要用多个架构的组合才足以满足一个复杂应用的需求。设计者需要根据实际情况来决定合适的架构选择。

接下来将展开谈谈3 Tier/N Tier架构......