0. 前言
在前一篇中我们创建了一个基于 EF 的数据查询接口实现基类，这一篇我将带领大家讲一下为这 EF 补充一些功能，并且提供一个解决避免写大量配置类的方案。
1. SaveChanges 的外移
在之前介绍 EF Core 的时候，我们提到过使用 EF 需要在每次使用之后，调用一次 SaveChanges 将数据提交给数据库。在实际开发中，我们不能添加一条数据或者做一次修改就调用一次 SaveChanges，这完全不现实。因为每次调用 SaveChanges 是 EF 向数据库提交变更的时候，所以 EF 推荐的是每次执行完用户的请求之后统一提交数据给数据库。
这样就会造成一个问题，可能也不是问题：我们需要一个接口来管理 EF 的 SaveChanges 操作。
1.1 创建一个 IUnitOfWork 接口
通常我们会在 Domain 项目中添加一个 IUnitOfWork 接口，这个接口有一个方法就是 SaveChanges，代码如下：
namespace Domain.Insfrastructure
{
public interface IUnitOfWork
{void SaveChanges();
}
}这个方法的意思表示到执行该方法的时候，一个完整的工作流程执行完成了。也就是说，当执行该方法后，当前请求不会再与数据库发生连接。
1.2 实现 IUnitOfWork 接口
在 Domain.Implement 中添加 IUnitOfWork 实现类：
using Domain.Insfrastructure;
using Microsoft.EntityFrameworkCore;
namespace Domain.Implements.Insfrastructure
{
public class UnitOfWork: IUnitOfWork
{
private DbContext DbContext;
public UnitOfWork(DbContext context)
{DbContext = context;}
public void SaveChanges()
{DbContext.SaveChanges();
}
}
}1.3 调用时机
到现在我们已经创建了一个 UnitOfWork 的方法，那么问题来了，我们该在什么时候调用呢，或者说如何调用呢？
我的建议是创建一个 ActionFilter，针对所有的控制器进行 SaveChanges 进行处理。当然了，也可以在控制器中持有一个 IUnitOfWork 的示例，然后在 Action 结束的时候，执行 SaveChanges。不过这样存在一个问题，可能会存在遗漏的方法。所以我推荐这样操作，这里简单演示一下如何创建拦截器：
在 Web 的根目录下，创建一个 Filters 目录，这个目录里用来存储一些过滤器，创建我们需要的过滤器：
using Domain.Insfrastructure;
using Microsoft.AspNetCore.Mvc.Filters;
namespace Web.Filters
{
public class UnitOfWorkFilterAttribute : ActionFilterAttribute
{
public IUnitOfWork UnitOfWork;
public override void OnActionExecuted(ActionExecutedContext context)
{UnitOfWork.SaveChanges();
}
}
}使用一个 ActionFilter 可以很方便的解决一些容易遗漏但又必须执行的代码。这里就先不介绍如何配置 Filter 的启用和详细介绍了，请允许我卖个关子。当然了，有些小伙伴肯定也能猜到这是一个 Attribute 类，所以可以按照 Attribute 给 Controller 打标记。
2. 创建一个简单的代码生成方法
之前在介绍 EF 的时候，有个小伙伴跟我说，还要写配置文件啊，太麻烦了。是的，之前我介绍了很多关于写配置文件不使用特性的好处，但不解决这个问题就无法真正体检配置类的好处。
虽然说，EF Core 约定优先，但是如果默认约定的话，得在 DBContext 中声明 DbSet<T> 来声明这个字段，实体类少的话，比较简单。如果多个数据表的话，就会非常麻烦。
所以这时候就要使用工具类，那么简单的分析一下，这个工具类需要有哪些功能：
- 第一步，找到实体类并解析出实体类的类名
- 第二步，生成配置文件
- 第三步，创建对应的 Repository 接口和实现类
很简单的三步，但是难点就是找实体类并解析出实体类名。
在 Util 项目中添加一个 Develop 目录，并创建 Develop 类：
namespace Utils.Develop
{
public class Develop
{}}定位当前类所在目录，通过
Directory.GetCurrentDirectory()这个方法可以获取当前执行的 DLL 所在目录，当然不同的编译器在执行的时候，会有微妙的不同。所以我们需要以此为根据然后获取项目的根目录，一个简单的方法，查找 *.sln 所在目录：
public static string CurrentDirect
{
get
{var execute = Directory.GetCurrentDirectory();
var parent = Directory.GetParent(execute);
while(parent.GetFiles("*.sln",SearchOption.TopDirectoryOnly).Length == 0)
{
parent = parent.Parent;
if(parent == null)
{return null;}
}
return parent.FullName;
}
}2.1 获取实体类
那么获取到根目录之后，我们下一步就是获取实体类。因为我们的实体类都要求是继承 BaseEntity 或者命名空间都是位于 Data.Models 下面。当然这个名称都是根据实际业务场景约束的，这里只是以当前项目举例。那么，我们可以通过以下方法找到我们设置的实体类：
public static Type[] LoadEntities()
{var assembly = Assembly.Load("Data");
var allTypes = assembly.GetTypes();
var ofNamespace = allTypes.Where(t => t.Namespace == "Data.Models" || t.Namespace.StartsWith("Data.Models."));
var subTypes = allTypes.Where(t => t.BaseType.Name == "BaseEntity`1");
return ofNamespace.Union(subTypes).ToArray();}通过 Assembly 加载 Data 的程序集，然后选择出符合我们要求的实体类。
2.2 编写 Repository 接口
我们先约定 Model 的 Repository 接口定义在 Domain/Repository 目录下，所以它们的命名空间应该是：
namespace Domain.Repository
{}假设目录情况与 Data/Models 下面的代码结构保持一致，然后生成代码应该如下：
public static void CreateRepositoryInterface(Type type)
{var targetNamespace = type.Namespace.Replace("Data.Models", "");
if (targetNamespace.StartsWith("."))
{targetNamespace = targetNamespace.Remove(0);
}
var targetDir = Path.Combine(new[]{CurrentDirect,"Domain", "Repository"}.Concat(targetNamespace.Split('.')).ToArray());
if (!Directory.Exists(targetDir))
{Directory.CreateDirectory(targetDir);
}
var baseName = type.Name.Replace("Entity","");
if (!string.IsNullOrEmpty(targetNamespace))
{targetNamespace = $".{targetNamespace}";
}
var file = $"using {type.Namespace};\r\n"
+ $"using Domain.Insfrastructure;\r\n"
+ $"namespace Domain.Repository{targetNamespace}\r\n"
+ "{\r\n"
+ $"\tpublic interface I{baseName}ModifyRepository : IModifyRepository<{type.Name}>\r\n" +
"\t{\r\n\t}\r\n"
+ $"\tpublic interface I{baseName}SearchRepository : ISearchRepository<{type.Name}>\r\n" +
"\t{\r\n\t}\r\n}";
File.WriteAllText(Path.Combine(targetDir, $"{baseName}Repository.cs"), file);
}
2.3 编写 Repository 的实现类
因为我们提供了一个基类，所以我们在生成方法的时候，推荐继承这个类，那么实现方法应该如下：
public static void CreateRepositoryImplement(Type type)
{var targetNamespace = type.Namespace.Replace("Data.Models", "");
if (targetNamespace.StartsWith("."))
{targetNamespace = targetNamespace.Remove(0);
}
var targetDir = Path.Combine(new[] {CurrentDirect, "Domain.Implements", "Repository"}.Concat(targetNamespace.Split('.')).ToArray());
if (!Directory.Exists(targetDir))
{Directory.CreateDirectory(targetDir);
}
var baseName = type.Name.Replace("Entity", "");
if (!string.IsNullOrEmpty(targetNamespace))
{targetNamespace = $".{targetNamespace}";
}
var file = $"using {type.Namespace};" +
$"\r\nusing Domain.Implements.Insfrastructure;" +
$"\r\nusing Domain.Repository{targetNamespace};" +
$"\r\nusing Microsoft.EntityFrameworkCore;" +
$"namespace Domain.Implements.Repository{targetNamespace}\r\n" +
"{" +
$"\r\n\tpublic class {baseName}Repository :BaseRepository<{type.Name}> ,I{baseName}ModifyRepository,I{baseName}SearchRepository" +
"\r\n\t{" +
$"\r\n\t\tpublic {baseName}Repository(DbContext context) : base(context)"+
"\r\n\t\t{"+
"\r\n\t\t}\r\n"+
"\t}\r\n}";
File.WriteAllText(Path.Combine(targetDir, $"{baseName}Repository.cs"), file);
}2.4 配置文件的生成
仔细观察一下代码，可以发现整体都是十分简单的。所以这篇就不掩饰如何生成配置文件了，小伙伴们可以自行尝试一下哦。具体实现可以等一下篇哦。
3. 总结
这一篇初略的介绍了两个用来辅助 EF Core 实现的方法或类，这在开发中很重要。UnitOfWork 用来确保一次请求一个工作流程，简单的代码生成类让我们能让我们忽略那些繁重的创建同类代码的工作。
更多内容烦请关注我的博客《高先生小屋》