.NET装配部署的一般设计

.NET装配从含义上说不但包括代码和元数据的可装载单元同时也表示其部署。为了开发出有效部署的系统，系统设计人员就必须仔细考虑.NET应用程序各个组成部分的正确部署位置。可是，这一方面一直没有相应的严格原则。在设计.NET装配时，你可以采用好几种方式管理软件开发和部署战略的粒度。下面就让我们了解一些有关的举措及其相应的优缺点。

通常我把装配的边界当作应用程序各层次（表示层、业务层和数据层）的边界，不过，在很多情况下也需要把某一特定层负责处理的任务分解到两个装配中去，其目的无非是满足技术上的某些需要。

一个装配（项目）一个组件

除非组件本身复杂的令人咋舌（这无论如何都不是一件好事），否则一个装配对应一个组件的开发粒度是很难管理的。开发适度规模项目的开发者会发现他很难编写各个组件文件之间的代码。而且，由于新版本引入到产品环境，所以你必须处理由此引发的版本问题。Visual Basic程序员倒是正好在这样的“恶劣”环境下成长起来的，原来，.NET框架出现之前的VB版本就只支持一个文件包含一个类的项目管理方式。不过，现在情况就发生变化了，采用任何.NET编程语言的开发人员都可以在基于单一文件管理多个类，从把相互关联的类组织到一起的角度看这样做自然合理多了。一个装配对应一个组件的方式使得应用程序在运行时对资源的要求更高。组件越多也就意味着装载组件的时间越长，管理这些组件所需要的内存和处理能力要求越大。

应用程序一层一装配

对众多的中小型项目而言，一个较为合理的办法是把应用程序某一层次所有有关的组件都放到一个装配中来。表示层、业务层和数据访问层的逻辑分离只是一种结构方式，其目的就是为了降低给各个层次增加特性所需要的额外的、必要的工作量。乍看起来，把组件物理地分派到代表应用程序各个层次的装配中是比较合理的。但是，虽然理论上确实如此，但是具体操作时会遇到相当程度的困难。

你应该这样想：那就是在必要的场合，把表示层、业务逻辑或者业务逻辑加上数据访问层放置在同一装配里，从而简化了部署和系统管理方面的工作。比方说，这种功能上的分布在紧耦合、高度交易性的环境下就几乎总是必要的，原因在于，在这样的环境中，由业务逻辑和数据库逻辑的分离而产生的应用程序执行速度的降低会阻止应用程序达到高效交易处理的业务需要。为业务和数据库层分别部署装配会引入进程间（在物理性的三层结构下）和计算机之间调用的额外负载，两种情况都会严重影响系统的运行速度。而把三层中的两层整合到同一装配和同一计算机上就会消除这一计算瓶颈。

按照功能而非层次组织装配

在更为复杂的应用程序中，有时更为合理的方法就是压根不按层次创建装配，而代之以按照功能分别创建装配。比如说，大型解决方案的某一子系统的业务逻辑及其关联的数据访问逻辑就不妨组织到单一的共享式企业服务包里。这样，你实际上在一台计算机上运行表示逻辑或者业务逻辑，然后从其他计算机应用这些子系统。用以上方法分离功能使得子系统可以在多个应用程序之间重用，相比仅仅共享数据访问层可方便多了。

在设计你的应用程序时，不妨多用点时间仔细考虑下设计装配来满足部署目标的问题。我就曾经目睹过这样的案例：系统设计师在决定系统各个部分的划分和功能时表现非常出色，结果令人满意，但恰恰在应用系统的时候失败了，原因就在于其设计恰好缺乏了系统部署这一块。