nopCommerce_4.4功能实现详解-----第1章 定义实现基础架构

“nopCommerce”为了让整个软件工程所实现功能，显得更加的条理浅析和具有逻辑性，“nopCommerce”把原来可以在程序启动项Startup类中直接定义的基础方法和操作(这里包含 Startup类的构造方法)，迁移到了“Nop.Core.Infrastructure”中进行定义,并按照所实现功能的不同把这些方法进行整合后定义在不同的类文件中。下面将按照这些类与其它类直接耦合程度（由低到高）来介绍它们所实现的基础功能。

第1章 定义实现基础架构

注意：

    .NetCore框架所实现的基石之一，就是依赖倒置思想。在技术实现上表现形式是类对象的实例化操作从类本身迁移到了该类所继承的接口。开发者如果在.NetCore框架基础上进行开发，在自定义类的同时也必须提供该类所承接的接口，以供程序可以通过承接的接口实现类对象的实例化操作。

0001、INopFileProvider、NopFileProvider

NopFileProvider类实现只与所继承的相应接口INopFileProvider产生直接耦合，在整个程序中的其它所有类中只存在间接的实例化调用，所以该类在“nopCommerce”软件工程中的耦合程度是最低的。

NopFileProvider类所实现的基础功能和操作是：使用拷贝构造方法获取服务器（程序启动项）的物理环境实例，进而在物理环境实例的基础上，自定义一些方法让后台管理者(角色)能够远程的通过客户端（浏览器）对服务器（程序启动项）中的文件或目录进行读、写、删除和移动等操作。

0002、BaseSingleton、Singleton

Singleton类实现只与所继承的BaseSingleton类实现相互之间产生直接耦合，在整个程序中的其它所有类中只存在间接的实例化调用，所以这两个类实现在“nopCommerce”软件工程中的耦合程度是最低的。

Singleton类和BaseSingleton类虽然在命名上是“单例”，但是在两者的所有定义中没有任何关于“单例”操作的方法或语句。BaseSingleton类的主要作用是通过拷贝构造方法进行实例化/初始化一个静态字典实例(即为字典实例分配内存空间)；在获取一个指定类或接口的类型的实例化静态对象后，把指定类或接口的类型的实例化静态对象及其相应的类或接口的类型映射的存储到静态字典实例中 (类或接口的类型存储在字典实例中的键(key)中， 相应的实例化对象存储在与该键(key)相对应的值(value)中）。

两个类虽然没有定义中任何关于“单例”操作的方法或语句，但是在两者所定义的静态字典实例值(value)中所存储的指定类或接口的类型的实例化静态对象则必须是“单例”的。例如：“EngineContext”类通过该类定义的“单例”操作的方法。把“IEngine” 类型和该类型实例化静态对象映射的存储到这两个类所定义的静态字典实例中。

为什么两个类没有接口声明?：

因为两个类中所定义的实现都为静态的，在程序被执行前已经被实例化过了，因此不需要进行注入操作，所以不需要对两个类进行接口声明。

0003、CommonHelper、NopException、SecureRandomNumberGenerator

“nopCommerce”为NopException类实现、SecureRandomNumberGenerator类实现与CommonHelper类实现，定义了一些通用的操作方法，为程序且在程序中这三个类实现和其它类实现之间，只存调用关系的间接耦合，所以这三个类实现在“nopCommerce”软件工程中的耦合程度是最低的。

SecureRandomNumberGenerator类： 

通过随机数生成器(RandomNumberGenerator ---RNG)实例来生成一个安全的随机数。

为什么该类没有接口声明? ：

因为该类只用于对其它类提支撑，而没有在启动项中使用，因此其实例化不需要进行注入操作，所以不需要对该类进行接口声明。

NopException类：

    “nopCommerce”通过【Nop异常--类】对系统异常类的继承，扩展并自定义系统异常类中的实现以达到实现方法所显示的异常信息满足“nopCommerce”所规定的格式和功能需求等目标。

为什么该类没有接口声明? ：

因为该类只的所有实现都是通过其相应的构造方法完成的，因此其实例化也是直接通过构造方法实现的，所以不需要对该类进行接口声明。

CommonHelper类：

    该类自定义实现了一些通用方法。这些方法主要功能是：输入验证、生成随机数、数据类型转换和日期计算等。

为什么该类没有接口声明?：

因为该类中所定义的实现都为静态的，在程序被执行前已经被实例化过了，因此不需要进行注入操作，所以不需要该类进行接口声明。

0004、ITypeFinder、AppDomainTypeFinder、WebAppTypeFinder

WebAppTypeFinder类实现继承于AppDomainTypeFinder类实现继承于ITypeFinder接口。三者相互之间产生直接耦合，在整个程序中的其它所有类中只存在间接的实例化调用，所以这三者在“nopCommerce”软件工程中的耦合程度是最低的。

AppDomainTypeFinder类：

    该类定义了程序集加载方法、验证模式(规则)属性。该类从开发者自定义的程序集和存储于应用程序域实例中的程序集中检索出所有符合验证模式(规则)程序集，最终获取这些程序集所对应类的类型实例，为批量进行反射依赖注入操作提供支撑（把类的类型实例作为依赖注入方法中的一个参数进行使用）。

WebAppTypeFinder类：

      该类主要是获取了存储所有DLL文件的文件夹在服务器端物理磁盘中的绝对路径字符串，在获取DLL文件的基础上，其基类中的操作对这些DLL文件所对应的程序集与验证模式(规则)进行匹配操作，如果匹配成功则获取这些程序集所对应类的类型实例，从而为批量进行反射依赖注入操作提供支撑（把类的类型实例作为依赖注入方法中的一个参数进行使用）。(我不知道有什么理由让“nopCommerce”把实现批量依赖注入的操作方法分别定义在两个类中，但我认为最好把WebAppTypeFinder和AppDomainTypeFinder定义进行合并，使整个定义显得不是那么臃肿)。

    对上述所有功能更为具体实现和注释见：21-05-10_Nop4.4(001_Nop.Core项目中的基本功能代码，并通过构建)。