系统架构师谈企业应用架构之服务层

/// <summary>  
/// 购物车  
/// </summary>  
public class ShopCar  
{  
/// <summary>  
/// 购物车中的产品  
　/// </summary>  
Dictionary<int, Product> products = new Dictionary<int, Product>();  
/// <summary>  
/// 将指定产品ID的产品添加到购物车  
/// </summary>  
public bool Add(int ID)  
{  
Product product = new Product();  
product= product.GetByID(ID);  
if (products.ContainsKey(ID))  
return false;  
products.Add(ID,product);  
return true;  
　}  
} 

下面我们来看看前台调用的代码：

public class ShopCar  
{  
/// <summary>  
/// 将指定产品ID的产品添加到购物车  
　/// </summary>  
public bool Add(int ID)  
{  
ShopCar cart = new ShopCar();  
return cart.Add(ID);  
}  
} 

上面的代码引用了ShopCar对象，说明UI层的ShopCar与业务层的ShopCar 有依赖关系，那么我们如何解耦呢？通过引入第三方类，来实现依赖的解除。具体

的代码如下：

public class ShopCar  
{  
/// <summary>  
/// 将指定产品ID的产品添加到购物车  
/// </summary>  
public bool Add(int ID)  
{  
IShopCar car;  
CarFactory factory = new CarFactory();  
car = factory.ShopCarFactory();  
car.Add(ID);  
return true;  
}  
} 

修改后通过服务层中的购物车工厂构造出购物车实例，这样就可以把业务逻辑层与界面层之间的耦合关系通过新增加一个服务层来实现解耦，那么表现层的代码更

简介，也符合设计规范。

其实我们这里的服务只是讲述了服务层的简单应用场景，其实具体的服务层在使用的过程中远比我们前面讲解的复杂，首先可能服务层还会与数据访问层直接交

互，比如说操作数据库，持久化等，服务层主要是组织业务逻辑中的业务逻辑组件，服务层还通过ORM框架中提供的数据库访问服务完成相应的操作。我们前面讲过，

一般情况下，表现层与服务层交互是，都是通过数据传输对象来进行通信的，那么显然有时候我们需要在服务层做处理，将数据传输对象转换成领域模型，当然有时候

我们在设计系统架构时，如果系统中的领域模型较多，或者说是拆分后的数据传输对象太多时，我们只要将一个领域模型对应一个数据传输对象就好，只不过是把领域

模型中的行为省略而已。

我们来看看目前比较流行的关于服务层的认识：

我想目前最流行的关于服务层的架构就是SOA（面向服务架构），可以说是SOA的出现才让服务层流行起来，SOA中对服务的理解是这样的，服务层是提供一系

列的服务，而具体的业务流程是通过一系列的服务组成的，把服务看作不是面向某种特定的技术，而是业务流程的组织方式。达到的目的是，提供了一系列的服务，只

需要配置组织服务的流程，就可以不管什么样的技术，都能满足要求的业务流程。当然这是理想化的形式，具体的实行起来还是有相当大的难度。

其实我们可以这样想象，服务就是一个提供了API的