 nopCommerce_4.40.3 功能实现详解-----第1章 基础架构

0001 NopException、SecureRandomNumberGenerator、CommonHelper

NopException类，该类继承于系统异常类的，并对系统异常类中相应实现方法进行自定义扩展，使这些方法的功能和对异常信息的显示，满足“nopCommerce”开发者所需要的功能和格式。

SecureRandomNumberGenerator类，通过随机数生成器(RandomNumberGenerator ---RNG)实例，来生成一个拥有极高安全性的随机数。虽然通过简单的调用rand()方法，也可以生成随机数，但是安全性和功能强度就不如该类所定义的实现了。

    CommonHelper类，该类自定义实现了一些程序中能够被经常用到的通用和常用方法，这些方法包括：输入验证、生成随机数、数据类型转换、泛型类型属性实例赋值和日期计算等。

    更为重要的是在该类中通过INopFileProvider接口声明了DefaultFileProvider静态属性，静态的限定结合整个“nopCommerce”程序对该静态属性定义/调用，共同保证了该静态属性实例，在一次整个程序的执行过程中能且只能被实例化一次，中间不存在任何关于该静态属性实例的覆盖性赋值的定义/调用。这种状况保证了程序在执行过程中只有一个实例通过相应的IO方法，能够对启动项中的相关文件夹/文件进行读写操作，这极大保证了启动项中的相关文件夹/文件的数据安全性，从这里可以看出“nopCommerce”开发者的功底和这么多的“nopCommerce”程序的版本迭代并不是白给的。

0002 INopFileProvider、NopFileProvider

    NopFileProvider类， 同时继承于INopFileProvider接口和PhysicalFileProvider类，该类通过所继承PhysicalFileProvider类调用服务器系统IO操作方法，自定义并扩展了一些IO操作方法用来对程序启动项中的目录/文件进行相应的操作。实际通过所定义的方法，让后台管理者(角色)能够远程的通过客户端浏览器，对服务器程序启动项中的目录/文件进行读、写、删除和移动等操作。

    PhysicalFileProvider类,是.NetCore框架内置的文件系统类，它的主要作用是以文件流的方式，让户端浏览器客户端浏览器，对服务器程序启动项中的目录/文件进行读、写、删除和移动等操作，即最终的操作是由PhysicalFileProvider类来实现的。

0003 ITypeFinder、AppDomainTypeFinder、WebAppTypeFinder

    AppDomainTypeFinder类，继承于ITypeFinder接口，同时也被WebAppTypeFinder类所继承，该类定义了程序集加载方法、验证模式(规则)属性。该类从开发者自定义的程序集和存储于应用程序域实例中的程序集中检索出所有符合验证模式(规则)程序集，并通过这些程序集（Assembly）中的接口/抽象类/类获取(检索)相应的具体实现类的类型实例，为构建抽接口/抽象类/类与相应的具体实现类的相互映射关系，以反射注入方式，依次注入到默认依赖容器或第三方依赖容器中等操作提供支撑。

WebAppTypeFinder类，该类主通过一个绝对路径字符串，获取持久化存储在服务器物理磁盘相应位置上bin文件夹中所有DLL文所对应的所有程序集，为其父类AppDomainTypeFinder具体实现类的类型实例检索操作提供支撑。

    我不知道有什么理由让“nopCommerce”的开发者，把上述这些关联性极强(耦合程度极高)的操作别定义在WebAppTypeFinder和AppDomainTypeFinder两个类中，但是本人认为最好是把这两个类中的定义实现，定义在一个类中来实现，使对具体实现类的获取(检索)操作显得不是那么割裂和碎片化。

0004 BaseSingleton、Singleton

       BaseSingleton类，该类通过其静态构造方法实例化/初始化一个字典实例(即为字典实例分配内存空间)，把一/多个，一个指定类的类型(键)及其该类型实例(值)所构建的键/值对，存储到该字典实例中。

       Singleton类，该类在构建的接口/抽象类/类的类型实例与相应具体实现类的静态实例的键/值对后，把该键/值实例存储到其父类实例的静态字典实例中。 (的接口/抽象类/类的类型实例存储在字典实例中的键(key)中， 相应的实例化对象存储在与该键(key)相对应的值(value)中）。

本人认为“nopCommerce”的开发者定义这两个类的因素是：通过极少量的特殊实例，对程序中大量存在的其它实例进行统一、有效管理的实现。实际上在这种管理方式在现实生活中极其见，只是“nopCommerce”的开发者把这种管理方式逻辑抽象应用到了，一个具有工程性质的程序实例的管理中，这各对现实的抽象应用，猛然碰到感到有些不适应。它也不像领域模式一样，在工程程序上使用的那么流行、广泛和自然，但不能否认这是一种工程程序实例管理方面的有效创新。

    由于上述因素。所以具有统一、有效管理功能的具体实现类的静态实例具有以下特性：

1. 具体实现类的静态实例必须统一、有效管理，程序中大量的其它类型的实例。
2. 具体实现类的实例必须是静态的且实例化/初始化的赋值操作有且只有一次，即该实例必须存在于一次程序执行的整个生命周期，不管是该实例的定义在整个程序的定义/调用中，实例化/初始化的赋值操作有且只能有一次，中间不能存在覆盖性赋值操作；还是该实例的定义实现被单例实例模式所定义。

1、 核心层通过NuGet引用Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation，从而保证MVC依赖注入中间件能够，通过AddRazorRuntimeCompilation()，Razo页面修改并保存后，刷新浏览器直接显示出修改后的效果。把该引用定义在核心层，可能是“nopCommerce”的开发者认为核心层是整个程序工程的最底层，从而不会造成得重复引用。

对以上功能更为具体实现和注释见：21-07-11_Nop_4.40.3(001_基础架构定义完成，并通过构建)。