服务架构
随便选一个服务，任何服务都可以，别告诉我具体是哪个：）。你可以找到一些处理传入的消息或请求的监听代码；你可以找到一些连接组件的代码，还有一些初始化并激活这个服务的代码；或许你还能找到一些能适当地配置服务的代码。有没有觉得我很厉害？实际上，你可以在服务里找到上面的所有代码，至少是大部分。
有许多工作都是重复性的、常见的。我们可以好好利用这一点。
如何使服务能够适应不同的配置，避免设置监听器、组件连接等重复性常规工作？
第一个办法（实际上也不是什么办法），就是为每一个服务重写所有的连接代码。很显然，这不是个好方法，因为重写的次数越多，就越可能产生一些缺陷。并且，对于维护来说，许多重复的代码产生的问题更为严重。在维护的时候，你不仅要确保每一个服务中的缺陷都已经得到修正，还要保证没有任何疏漏、所有的服务都已经同步更新。
另一个相对较合理的办法，就是创建一个共同任务库，所有的服务都通过API与库相连接。这样确实会有所帮助，但是为了充分利用库的功能，你仍然需要编写连接代码。
还有一个办法是利用继承创建一个超类，用超类实现共同的功能，然后让各个服务继承这个类。然而利用继承也有问题，因为服务的功能通常无法通过一个单独的类获得很好的实现。此外，不同的服务所处理的业务也完全不同——否则它们就是一样的服务了。因此，也无法让把这些服务归于同一类结构。
服务托管就像是一个肩负着许多职责的迷你框架。它的第一个职责就是正确地示例服务所包含的组件或类。服务托管还负责读取配置信息，比如，它可以读取服务消费者用来连接服务的端口。其它职责包括创建服务环境，比如在终端创建监听器。最后，服务托管可以负责连接组件——终端监听器上的协议绑定或者创建一个与数据库的连接。所有这些职责的共同特征是它们都与服务的实例化和初始化有关，并且正如我们在问题部分所描述的一样，你很可能会在多个服务中遇到同样的情况。前面已经提到，服务托管是一个框架，与第二种方法中描述的库的概念有所不同。库是一个实用类或方法集，你可以调用它们来获取特定的功能。而框架则包含了一些功能或流程，并通过调用代码来扩展流程或将其转变为具体的流程。这就是“控制反转（Inversion of Control）”原理。这种原理已经在面向对象的框架中获得广泛的应用，比如Spring或Spring.NET、Picocontainers等。
一个服务托管可以托管多个服务——虽然这种情况可能并不常见。我们曾经构建了一个系统，使用的方案规模小到一台计算机即可应付。这真的很方便。如果换另一种方案，那么服务可能就要扩展到多台计算机上，这样你就得应用多个服务托管实例，各个主机托管服务的一部分，而不是整个服务。