所谓服务粒度是指直接影响到了服务的质量，包括灵活性和效率等。所以选择合适的粒度对服务设计是至关重要的。那么要识别并设计一个粒度适中的服务，主要从以下三个方面来权衡考虑。

1.重用性
粒度的大小直接影响到了服务的可重用性。一个简单的经验法则就是细粒度的服务更容易被重用。换句话说，就是颗粒度越粗，服务越少被重用或者越难以被重用。因为随着颗粒度的增加，越来越多的业务规则和上下文信息会被嵌入到业务逻辑中，服务逐渐变得具有特定的业务意义了。要使用它，我们必须首先了解它到封装了哪些规则，否则我们无法确信这个服务正是我们所需要的。

在了解了内存机制和熟悉了通用规则的基础上，我们就可以很好地总结出值类型和引用类型在系统设计时，如何做出选择，如何去选择使用值类型。因为引用类型才是.NET的主体，所以它在大部分的场合中已经受到了青睐。

1.值类型的应用场合

1）MSDN中建议以类型的大小作为选择值类型或者引用类型的决定性因素。数据局较小的场合，最好考虑以值类型来实现系统性能的改善。

2）结构简单，不必在多态的情况下，值类型是较好的选择。

3）类型性质不表现出行为时，不必以类来实现，那么以存储数据为主要目的的情况下，值类型是优先的选择。

依赖底层模块，二者都要依赖与抽象；2）抽象不应该依赖细节，细节应该依赖与抽象。

依赖倒置原则(DIP)，通过使代码依赖抽象而不依赖具体实现的方式来达到解耦的目的。让我们先来回顾一下DIP的定义吧：1）高层模块不应该依赖底层模块，二者都要依赖与抽象；2）抽象不应该依赖细节，细节应该依赖与抽象。

简单点说就是：依赖与抽象，或者可以说程序中所有的依赖关系都应该终止于抽象类或或接口。根据这个理解可以得出以下原则：

1.任何变量都不应该持有一个指向具体类中已经实现了的方法。

企业存储应用的体系结构主要有DAS、NAS和SAN三种模式，下面让我们来看一下它们各自的发展趋势吧！

首先，DAS直连存储的最大弊病在于，各部分的存储资源相互隔离，容易形成孤岛。

其次，NAS具有无人值守、高度智能、性能稳定、功能专一等特点，但NAS技术不能满足可靠度为99.999%的数据存储系统的要求。

最后，SAN的最大优势则在于，可以把异构环境下不同厂商的存储设备整合在一起，实现资源的共享，因此SAN将成为企业存储应用的主流。

为了保证数据在不同的影响建平台、不同的操作系统下流转畅通，存储架构的开放性、存储硬件的兼容性、存储软件的适应性就必须要归结在一起，即表现为存储的融合，也就是说SAN与NAS融合是大势所趋；另一方面，虚拟存储使主机操作系统看到的存储与实际物理存储分开了，虚拟存储技术可提高存储设备的利用率，通过动态地管理磁盘空间，虚拟存储技术可以避免磁盘空间被无效占用。目前虚拟技术已经引起了几乎所有存储系统厂商的关注，采用虚拟存储技术的设备将成为市场的新主流。

在IT创业产品互推平台中有大量的文件需要存储，并且文件存储设计的好坏将会对整个SNS的使用产生巨大的影响，特别是在性能方面。

1.单独磁盘存放文件
对于用户上传的文件，很多时候是保存在服务器的磁盘上的。在IT创业产品互推平台站点发展的初期，可能只存在一台服务器，此时，数据库和用程序都会部署在这台服务器上面。

2.独立服务器存放文件
随着SNS站点的发展，文件的上传和下载在服务器上产生了大量的I/O操作。此时服务器的I/O将会成为整个系统的性能瓶颈，而且还会影响数据库及站点的响应能力，因为I/O操作会消耗大量的CPU、内存等资源。此时就需要采用独立的服务器来进行文件处理操作了。

在网站建设中遇到很多技术问题，不同的问题要得到不用的解决方法，用到的技术也不一样。下面我们就了解了什么是SOA之后，让我们来了解一下常被重点提及的SOA原则：

面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

1.边界清晰

意味着服务可以部署到任何地方，并且可以被其他的服务轻松自由的访问，不用管其他服务环境或开发语言是什么。

在设计中，业务层常常可以进一步细分为：业务逻辑单元和应用逻辑单元，其中业务逻辑单元包含各种处理逻辑和验证规则；应用逻辑单元则是由服务类组成的“薄层”，负责提供粗粒度的接口方法，以供外界使用。

显示层可以通过调用应用层进行逻辑操作，而且显示层还可以直接绕过应用逻辑层，从而调用业务类进行相关的逻辑处理。

在设计中，有时候为了增加灵活性和扩展性，我们希望显示层不依赖业务类，这样就可以让业务类的结构变化不影响显示层为了达到这个目的，数据的交换则需要用数据传输对象（DTO）来辅助完成。

外观（Facade)模式简化了复杂子系统的调用接口，并且隐藏了子系统之间的复杂关系，只在网站建设编码过程中给客户端一个简单的调用接口。

(1)客户程序调用Facade的一个简单API来执行一个任务，可能这个任务的执行会涉及很多内部子系统的交互和合作，但是客户程序完全不知道Facade内部是如何实现的。

(2)SubSystemA和SubSystemB才是任务的真正执行者。

相较于其他模式而言，Facade模式可以说是一个比较容易理解的模式，不过其中也存在着几个比较容易混淆的问题，为了进一步理解Facade模式在服务层中的应用，下面就来看看这几个问题。

数据传输对象是一个为了减少网站建设编码过程中方法调用次数而在进程间传输数据的对象。

网站建设编码中当使用远程接口时，例如使用远程外观模式，那么每一次调用的代价都是非常大的。所以需要减少调用的次数，这就意味着每一次的调用都会传输大量的数据，可通过多种方法达到此目的，例如传人大量的参数，但是这样会使应用很笨拙，而且不灵活。

解决的办法就是传递一个数据传输对象，这个对象将保留调用需要用到的所有数据。它需要被序列化以便能在进程中传输。通常，在服务端有一个转换器，这个转换器负责在DTO与业务对象之间进行数据的转换。

延迟加载（Lazy Load)表示直到需要的时候才去加载所需要的资源。例如，在一个订单管理系统中，每个Customer都有自己的订单，当获取Customer的时候，我们可能并不希望同时也去获取他的订单，只有在需要的时候，才会回去获取。在这种情况下若采用延迟加载订单的方 式，系统能够迅速地将Customer的信息返回，并且也减轻了数据库的负担。

实现延迟加载的方式有四种：延迟初始化、虚代理、值保持和重影。

下面通过虚代理来讲述有关延迟加载的知识。虚代理看起来应该是我们需要的对象，但是 实际上它不包含任何东西，只有在调用它的方法时，它才会去加载恰当的对象。