《.NET应用架构设计：原则、模式与实践》新书博客--试读-2.1.2 设计原则实战-低调大师

《.NET应用架构设计：原则、模式与实践》新书博客--试读-2.1.2 设计原则实战

2017-11-14 603

2.1.2 设计原则实战

下面我们就以一个简单的电子商务系统为背景：通过给定的产品分类ID获取该分类下的所有产品。

对于这个问题，基本上不用想就可以实现，如图2-1的类图设计。

图2-1 获取分类产品的类图

其中：

q ProductService类被客户程序调用，通过调用GetAllProductsFrom方法来获取产品，并且此处还可以添加缓存策略或异常处理等机制。

q Product类代表了产品的实体。

q ProductRepository类用来从数据存储设备（数据库或XML等其他数据存储器）中读取产品信息。

注意为了减少读者不必要的麻烦，让理解更加直观，以后的章节中，都会给出完整的代码示例和项目图示。

在这个示例中，Visual Studio项目的结构图如图2-2所示。

图2-2 Visual Studio解决方案图

正如之前所说：ProductService提供外部调用的方法接口，并且采用了缓存策略和异常处理机制，来提高程序的性能和健壮性，代码如下所示：

using System;

usingSystem.Collections.Generic;

usingSystem.Web;

using AgileSharp.Chapter2.Repository;

using AgileSharp.Chapter2.Domain;

namespace AgileSharp.Chapter2.Service

{

public class ProductService

{

private ProductRepository productRepository = null;

public ProductService()

{

productRepository = new ProductRepository();

}

public List<Product> GetAllProductsFrom(intcategoryId)

{

List<Product> result = new List<Product>();

try

{

string cacheKey = string.Format( "products_in_category_{0}"，categoryId);

result = HttpContext.Current.Cache.Get(cacheKey) as List<Product>;

if (result == null)

{

result = productRepository.GetProductsFrom(categoryId);

if (result != null &&result.Count> 0)

{

HttpContext.Current.Cache.Insert(cacheKey， result);

}

catch (Exception ex)

{

//Log will add here later

}

return result;

}

至于 Product 和 ProductRepository 的代码就非常简单了，这里不多解释。

示例到这里，也许大家有个疑问：上面的代码有些什么问题？

q ProductService 依赖于 ProductRepository 。在没有任何变化的情况下，这没有什么问题。但是如果现在项目换了数据存储设备，例如将数据库换成了 XML 文件，或者数据库的访问技术从 ADO.NET 换成了 Entity Framework ，那么 ProductRepository 的代码就得改变，这会使得整个项目都需要重新编译，重新部署。问题来了：此时系统中只有 ProductRepository 一个变化点，为什么非得要求整个项目重新编译，重新部署呢？难道不能只重新编译和部署那个变化的模块呢？

q 代码不具有测试性能。要想知道此段功能代码是否按照了我们的意愿运行，可以通过人工审核，然后通过 GUI 界面获取数据来进行调试，此时的逻辑相对而言比较简单，此方法也还行得通。不过，一旦业务逻辑变得复杂或代码量的剧增，那么很难确保代码不会出错，而这些错误很多时候只会在运行时才能被发现。

q 缓存机制依赖于 HttpContext ，这不仅仅会让测试产生困难（尽管可以有 Mock ），而且会对后续系统的扩展有阻碍（例如采用分布式缓存）。

对以上的问题进行进一步分析，可以知道，这都是因为违背了以下设计原则：

q ProductService 依赖了 ProductRepository 的具体实现，而 ProductRepository 是一个可能的变化点。也就是说： ProductService 这个高层模块依赖了 ProductRepository 底层模块，违背了依赖倒置原则，这也就使得一个 ProductRepository 变化，整个项目都需要重新编译，重新部署。同理，缓存机制也是。

q 对于可测试性的问题，严格来说，上面的代码是可以测试的，但是测试的时候必须依赖于外部的数据存储设备，例如数据库，那么测试的结果可能会由于数据的变动而不一样，而且每次测试所花的时间也会比较长。

接下来尝试重构上面的代码，让代码的组织方式更加的灵活和易于扩展。

既然上面代码主要是违背了 DIP依赖倒置原则（再次回顾一下DIP：依赖抽象，而不依赖具体实现）。

那么现在就提出接口 IProductRepository ，使得 ProductService 依赖这个接口，代码如下：

using System.Collections.Generic;

using AgileSharp.Chapter2.Domain;

namespace AgileSharp.Chapter2.Repository

{

public interface IProductRepository

{

List<Product> GetProductsFrom(intcategoryId);

}

现在接口已经抽象出来了，ProductService可以直接依赖接口了，但是我们现在还需要一个实现IProductRepository接口的类ProductRepository，然后再采用LSP（里氏替换原则），用ProductRepository替换。代码如下：

using System;

usingSystem.Collections.Generic;

using AgileSharp.Chapter2.Domain;

namespace AgileSharp.Chapter2.Repository

{

public class ProductRepository：IProductRepository

{

//…

}

现在 ProductService 的代码如下所示：

using System;

usingSystem.Collections.Generic;

usingSystem.Web;

using AgileSharp.Chapter2.Repository;

using AgileSharp.Chapter2.Domain;

namespace AgileSharp.Chapter2.Service

{

public class ProductService

{

privateIProductRepositoryproductRepository = null;

publicProductService()

{

productRepository = new ProductRepository();

}

public List<Product> GetAllProductsFrom(intcategoryId)

{

//...

}

其实可以看到，上面 ProductService 的代码虽然提出了抽象接口，但问题依然存在：仍依赖于 ProductRepository 的具体实现。

问题到这里就好办了，可以采用工厂模式，通过读取配置文件进行反射或采用依赖注入等方法得到解耦。

可以看出：设计原则解决了变化点的问题，将 ProductRepository 这个变化点从 ProductService 中移出，然后一步步的迁移，最后把这个变化点引到了配置文件中，也就是将变化点引到了系统之外，也许这些正是我们需要的。

当当网：http://product.dangdang.com/product.aspx?product_id=22574513

京东地址： http://book.360buy.com/10893935.html

卓越地址： http://www.amazon.cn/mn/dp/B006NS2N0S

本文转自yanyangtian51CTO博客，原文链接：http://blog.51cto.com/yanyangtian/758289 ，如需转载请自行联系原作者

微信关注我们

原文链接：https://yq.aliyun.com/articles/464931

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

开机无须登录直接进入桌面

Record- Remember 开机无须登录直接进入桌面,以满足懒人不输入密码直接进入桌面，或在虚拟化架构中，可以利用旧配置主机直接到桌面，提高用户体验。 1、在运行对话框中，输入注册表编辑命令regedit，来打开注册表编辑窗口； 2、在该窗口中，依次展开HKEY_LOCAL_MACHINES\SOFTWARE\Microsoft\WindowsNT\Current Version\WinLogon键值； 3、在对应右边的子窗口中，用鼠标右键单击空白处，从弹出的快捷菜单中，依次执行“新建”/“字符串”命令，来创建一个字符串类型的键名，并将键名设置为“AutoAdminLogon”，并将该键名的数值设置为“1”； 4、双击“DefaultUserName”键名，在随后打开的窗口中，直接输入要登录到此域的用户名，例如“morning”； 5、在WinLogon右边的子窗口中，用鼠标右键单击空白处，从弹出的快捷菜单中，依次执行“新建”/“字符串”命令，来创建一个字符串类型的键名，并将键名设置为“DefaultPassword”，并将该键名的数值设置为用户登录系统的密码，例如用户morni...

2017-11-15

488

　圣殿骑士自从入住博客园和51CTO写技术博客以来收获颇多，在这个过程中既对技术有了新的收获，同时也认识了很多朋友。之前由于工作和项目需要，所以对一些技术进行了较为深入的研究，在整个公司做过一些技术专场的培训（如“OO到设计模式”、“WCF基础到企业应用”、“WPF基础到企业应用及优化”、 “Silverlight基础到企业应用及优化”等），所以在写博客的时候也比较循规蹈矩，大家可以看到WPF系列基本就是按照培训的格式书写，只是比培训说得要深入一些。虽然写技术博客在某种程度上弥补了培训的不足，但同时也是一项非常耗费时间和精力的事情，有很长一段时间都在断断续续的延续这份激情。总结一下，最近文章进度缓慢最主要原因应该归功于以下两个方面： 1，自己经不起诱惑，在忙着为出版社写书，不过写了很久才写三章，综合发现写书是一个良心活。要想写得一般比较容易；要想写得深入浅出确实需要花费很大的时间和精力；经过慎重思考，还是决定先缓一缓写书的进度，继续为大家书写一些技术相关的文章，分享一些自己浅薄的心得，希望能在帮助他人的同时也能提高自己！ 2，由于自己比较懒，没事的时候也会享受一下生活，毕竟...

2017-11-15

490

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。