第5章泛型服务的定义实现

最新推荐文章于 2023-05-23 17:42:20 发布

zhoujian_911

最新推荐文章于 2023-05-23 17:42:20 发布

阅读量374

点赞数

分类专栏：前后端分离之博客实现(anjoy8) 文章标签： .Net7 前后端分离博客实现后端

本文链接：https://blog.csdn.net/zhoujian_911/article/details/128023777

版权

前后端分离之博客实现(anjoy8) 专栏收录该内容

17 篇文章 1 订阅

订阅专栏

从本章开始进入“Blog.Core-master”示例程序内部，但是也逐渐发现该程序是1个示例性远远大于工程性的程序，其内部有着些不必要的定义，同时在定义的规范上也存在着大小的许多问题，例如：一致性的命名方式规范，大量的不必要切重复的代码，不知从那儿复用的设计定义精巧但实用性和可读性都极差的类等，所以“Blog.Core-master”程序只能作为功能性研究的示例程序，其实从该程序的实体类的定义就很能体现示例程序的特性，但不能确定，随着不断的深入该程序的示例性特性不断被新的定义所证实。该程序不能作为开发时参考的工程性项目，如果没能一定的鉴别能力本人不建设对该示例程序进行学习。

1 “Blog.Core-master”示例程序的缺陷

1、当前程序通过工作单元模式与仓储模式结合的方式通过“SqlSugar”中间件实现了当前程序与数据库表的CURD交互操作，但在当前实际的工程实现上工作单元模式已经逐渐的式微，而被广泛使用的是对泛型仓储的继承来实现“SqlSugar”中间件实现了当前程序与数据库表的CURD交互操作。

2、重复定义了泛型仓储的类及其接口和泛型服务类及其接口，造成了大量的且不必须的重复代码，如果直接使用具体服务类调用泛型仓储的类及其接口就可以解决这个问题。

3、泛型仓储的类和泛型服务类有大量的事代码，例如分页实现中有：

/// <param name="whereExpression">查询条件“lambda”表达式实例，只有符合该表达式实例的条件，实例才能被存储到列表实例中(“Where”操作，把表中有数据的字段都赋值给相应实例的属性成员)。</param>

/// <param name="pageIndex">当前页面的整型值，默认值：1，即第1逻辑页面。</param>

/// <param name="pageSize">每1页中最多包含行数的整型值，默认值：20，即每1逻辑页面内最多包含20行数据。</param>

/// <param name="orderByFields">排序条件字符串，默认值：null，即按照表所给的默认排序规则。</param>

/// <summary>

/// 【分页查询】

/// <remarks>

/// 摘要：

/// 从指定表中获取指定实体的符合条件的排序后的指定1逻辑页面内的所有实例，并最终这些实体的实例存储到页模型(PageModel)实例中(“Where”操作，把表中有数据的字段都赋值给相应实例的属性成员)。

/// 注意：

/// 当前类中只用该分页方法经过原开发者测试，其它的方法开发者都未测试。本人认为作为1个示例性为主的项目，开发者应该简化实现，而不是无用的实现堆砌到程序中。

/// <returns>

/// 返回：

/// 页模型(PageModel)实例，该实例存储着指定实体的符合条件的排序后的指定1逻辑页面内的所有实例(“Where”操作，把表中有数据的字段都赋值给相应实例的属性成员)。

/// </returns>

/// </summary>

public async Task<PageModel<TEntity>> QueryPage(Expression<Func<TEntity, bool>> whereExpression, int pageIndex = 1, int pageSize = 20, string orderByFields = null)

方法是经过开发者测试且被使用的，其他的都是为功能扩展预留的堆砌，但作为示例性程序中开发者应该简化实现，而不是无用的实现堆砌到程序中，即使在工程性程序中为功能扩展预留的堆砌也极少，最好的解决方案是在下1个版本中再集成相应的功能，而不是扩展预留。

4、、泛型仓储的类和泛型服务类中的所有CURD方法都是异步实现，所有的方法名后都要加上“Async”后缀字符串，以显式的方式来向其它开发者说明这些方法是异步方法。

5、不知“DynamicLinqFactory.cs”文件中的定义是开发从哪儿复用过来的，该文件中对Link的扩展实现十分的精巧，会为CURD的定义实现提供一定的简洁性，但是相对于它的实用性不强，扩展定义实现极其复杂且不必要，使整个扩展定义显得实现逻辑混乱，可读性极差，显得及其糟糕，这是我见过的最差的扩展实现。

009 PaginationModel、PageModel<T>、MethodInfoExtensions、LinqHelper、LinkSymbol、OperationSymbol、DynamicLinqHelper、DynamicLinqFactory、QueryableExtensions

PaginationModel：该实体类及其属性成员，所存储的实例为逻辑分页操作提供数据支撑。

PageModel<T>：该类用于存储，通过该类及其成员，把1指定逻辑页面内的指定实体/模型的所有实例存储到该逻辑分页类的实例中。

MethodInfoExtensions：通过该类中的方法成员，获取1个指定方法的全名字符串。

LinqHelper：通过该类中的成员方法，为指定类的1个指定实例的Linq操作，拼接出1个“真(x => true)”“lambda”表达式实例；或拼接出1个“假(x => false)”“lambda”表达式实例。

LinkSymbol：该枚举为指定类的1个指定实例的Linq操作的“lambda”表达式实例实例拼接可能包含的3种枚实例的逻辑运算符，它们分别是：AndAlso(&&;&)/OrElse(||;|)/Empty/Oracle/（将来可能会包含括号）。

OperationSymbol：该枚举为指定类的1个指定实例的Linq操作的“lambda”表达式实例拼接中可能包含的8种枚举实例操作和运算符，它们分别是： In(In后面跟着的是数据源)/Contains(包含，“like/contains”)/GreaterThan(大于，“>”)/GreaterThanOrEqual(大于等于，“>=”)/LessThan(小于，“<”)/ LessThanOrEqual(小于等于，“<=”)/Equal(等于，“==/=”)/NotEqual(不等于，“!=”)。

DynamicLinqHelper：通过该类中的属性成员，为指定类的1个指定实例的Linq操作，动态拼接“lambda”表达式实例的拼接提供数据支撑。

DynamicLinqFactory：通过该类中的成员方法，为指定类的1个指定实例的Linq操作，拼接出1个“lambda”表达式实例。

QueryableExtensions：通过该类中的成员方法，定义指定类的1个指定实例的Queryable扩展操作实现。

注意：

LinkSymbol、OperationSymbol、DynamicLinqHelper、DynamicLinqFactory和QueryableExtensions都定义在“DynamicLinqFactory.cs”文件中。

010 UnitOfWork、IUnitOfWorkManage、UnitOfWorkManage、

IBaseRepository<TEntity>、BaseRepository<TEntity> 、

IBaseServices<TEntity>、BaseServices<TEntity>

UnitOfWork：该类用于存储，该类及其成员，用于在工作单元模式下，为当前程序通过“SqlSugar”中间件与(多数据库软件中的)数据库的交互操作提供数据和方法支撑。

IUnitOfWorkManage接口：继承该接口的具体实现类中的方法成员，用于在工作单元模式下，实现当前程序通过“SqlSugar”中间件与(多数据库软件中的)数据库的交互操作。

UnitOfWorkManage：继承了IUnitOfWorkManage接口，该类中的方法成员，用于在工作单元模式下，实现当前程序通过“SqlSugar”中间件与(多数据库软件中的)数据库的交互操作。

IBaseRepository<TEntity>接口：继承于该是接口的具体实现类中的泛型方法成员，用于在仓储模式下，以异步方式实现了当前程序通过“SqlSugar”中间件与(多数据库软件中的)数据库的CURD交互操作。