然而，最理想的方式仍然是面向接口设计。根据第28章对ASP.NET缓存的分析，我们可以将表示层App_Code下的Proxy类与Utility类划分到业务逻辑层中，并修改这些静态类为实例类，并将这些类中与业务领域有关的方法抽象为接口，然后建立如数据访问层一样的抽象工厂。通过“依赖注入”方式，解除与具体领域对象类的依赖，使得表示层仅依赖于业务逻辑层的接口程序集以及工厂模块。
那么，这样的设计是否有“过度设计”的嫌疑呢？我们需要依据业务逻辑的需求情况而定。此外，如果我们需要引入缓存机制，为领域对象创建代理类，那么为领域对象建立接口，就显得尤为必要。我们可以建立一个专门的接口模块IBLL，用以定义领域对象的接口。以Product领域对象为例，我们可以建立IProduct接口：
public interface IProduct { IList GetProductByCategory(string category); IList GetProductByCategory(string[] keywords); ProductInfo GetProduct(string productId); }
在BLL模块中可以引入对IBLL程序集的依赖，则领域对象Product的定义如下：
public class Product:IProduct { public IList GetProductByCategory(string category) { //实现略; } public IList GetProductByCategory(string[] keywords) { //实现略; } public ProductInfo GetProduct(string productId) { //实现略; } }
然后我们可以为代理对象建立专门的程序集BLLProxy，它不仅引入对IBLL程序集的依赖，同时还将依赖于BLL程序集。此时代理对象ProductDataProxy的定义如下：
using PetShop.IBLL; using PetShop.BLL; namespace PetShop.BLLProxy { public class ProductDataProxy:IProduct { public IList GetProductByCategory(string category) { Product product = new Product(); //其他实现略; } public IList GetProductByCategory(string[] keywords) { //实现略; } public ProductInfo GetProduct(string productId) { //实现略; } } }
如此的设计正是典型的Proxy模式，其类结构如图5-2所示：
图5-2 Proxy模式
参照数据访问层的设计方法，我们可以为领域对象及代理对象建立抽象工厂，并在web.config中配置相关的配置节，然后利用反射技术创建具体的对象实例。如此一来，表示层就可以仅仅依赖PetShop.IBLL程序集以及工厂模块，如此就可以解除表示层与具体领域对象之间的依赖关系。表示层与修改后的业务逻辑层的关系如图5-3所示：
图5-3 修改后的业务逻辑层与表示层的关系
图5-4则是PetShop 4.0原有设计的层次关系图：
图5-4 PetShop 4.0中表示层与业务逻辑层的关系
通过比较图5-3与图5-4，虽然后者不管是模块的个数，还是模块之间的关系，都相对更加简单，然而Web Component组件与业务逻辑层之间却是强耦合的，这样的设计不利于应对业务扩展与需求变更。通过引入接口模块IBLL与工厂模块BLLFactory，解除了与具体模块BLL的依赖关系。这种设计对于业务逻辑相对比较复杂的系统而言，更符合面向对象的设计思想，有利于我们建立可抽取、可替换的“抽屉”式三层架构。
以上就是PetShop的业务逻辑层设计全部内容，希望能给大家一个参考，也希望大家多多支持脚本之家。
您可能感兴趣的文章: