【开源】OSharp框架解说系列（5.1）：EntityFramework数据层设计

OSharp是什么？

　　OSharp是个快速开发框架，但不是一个大而全的包罗万象的框架，严格的说，OSharp中什么都没有实现。与其他大而全的框架最大的不同点，就是OSharp只做抽象封装，不做实现。依赖注入、ORM、对象映射、日志、缓存等等功能，都只定义了一套最基础最通用的抽象封装，提供了一套统一的API、约定与规则，并定义了部分执行流程，主要是让项目在一定的规范下进行开发。所有的功能实现端，都是通过现有的成熟的第三方组件来实现的，除了EntityFramework之外，所有的第三方实现都可以轻松的替换成另一种第三方实现，OSharp框架正是要起隔离作用，保证这种变更不会对业务代码造成影响，使用统一的API来进行业务实现，解除与第三方实现的耦合，保持业务代码的规范与稳定。

本文已同步到系列目录：OSharp快速开发框架解说系列

前言

　　数据层设计真是一个百说不厌的话题，大系统说并发量，说高性能；小系统追求开发效率，易维护性各有各的追求。

　　OSharp 开发框架的定位是中小系统，数据层的开发效率与易用性的权重就比较高了，所以，使用ORM当然是首选。在 .net 环境下，有众多的闭源的开源的优秀的ORM组件，从各方便对比来看，EntityFramework 是不二之选。一提起 EntityFramework，不少同学又要蠢蠢欲动来吐槽其性能了。其实，经过几个版本的更新换代，现在的稳定版 EntityFramework 6 已经相当好用了，nuget 上截止到目前 “8,830,918 total downloads” 已经足够能说明问题了，EntityFramework 在整个 .net 世界是相当受欢迎的。不过，不管哪个技术平台，能不能用好一个技术与技术水平有很大的关系，如果没追求，随处的 select * from xxx，传说中高性能的 ado.net 也不会高到哪去。

为什么强依赖于EntityFramework

　　在本系列开篇《总体设计》对 OSharp 开发框架的数据存储组件的介绍时，就强调了 OSharp 将“强依赖”于 EntityFramework 这个数据访问组件。当时就有人提出了“强依赖Entity framework是个坑吧”的疑问。这里简要解释一下为什么 OSharp 不打算做成兼容各种数据访问方案（EF，NH，ado.net 等等）。我们来看看统一各个ORM需要付出的代价：

需要统一标准，业务层与数据层之间的数据交互载体只能是POCO数据实体，如果个别ORM需要对实体有特殊要求（如NH要求实体属性为virtual），需要在ORM实现内部进行适配转换。
数据交互只能是实体，这就导致了参数数据查询的所有 sql 语句都是“select * from ...”这种方式，这将给系统性能带来伤害。
要兼容各个ORM，数据层只能提供一些能普遍适应的 API，放弃各种 ORM 的优点与特色（如EF的linq查询）

　　基于上面的一些理由，我们发现要兼容各种数据访问方案，需要付出的代码是很大的，很不划算。因此，OSharp 将专注于一款 ORM，从各方面比较，EntityFramework 是一个好选择，理由如下：

EntityFramework 是微软大力发展的一个开源项目，EF 6 在 codeplex.com 开源，EF 7 在 github.com 随 ASP.NET 5 开源。
EntityFramework 能轻松支持各大主流数据库，只要引入相应数据库的 DataProvider 即可，能无差异的操作各大主流数据库。
EntityFramework 支持 linq to entities 语句查询，强类型支持，高效实现查询需求。
EntityFramework 全面封装了数据库细节，使用了大量的“约定胜于配置”的思想，使开发者不必直接对关系存储架构编程，减少代码量，减轻维护工作，并使项目可维护性更高。

为什么要封装EntityFramework

　　在计划使用EntityFramework来在项目中实现数据存储时，遇到的第一个问题就是：怎样来使用EntityFramework？要不要对EntityFramework进行二次封装？

　　反对对 EntityFramework 进行封装的同学，通常会有如下理由：

EntityFramework 提供的API已经足够简单了，已经有了非常良好的易用性，没有再封装的必要。
EntityFramework 内部已经实现了一个 UnitOfWork + Repository 的封装，没有必要再包装一次。
EntityFramework 提供的API非常灵活且很有特色，封装有可能会丧失其灵活性

　　我认为，如果是小项目，且所有开发成员都能很好的使用 EntityFramework，在业务层中直接使用，将 EntityFramework 的灵活性发挥出来，也是非常好的。但是，直接使用 EntityFramework 的话，也有不少弊端，对于 OSharp 这样一个开发框架而言，封装就显得非常有必要了，原因如下：

不是所有的开发人员都对 EntityFramework 足够熟悉，封装之后能将 EntityFramework 的细节及较敏感的 API 进行包装与隐藏，使 EntityFramework 的使用更加透明易用。
统一的封装，有利于对业务层提供统一的 API，对业务层的代码规范非常有利。
封装有利于业务实体与 EntityFramework 的解耦。如果不封装，所有业务实体模型（Model）都要在上下文类中设置一个 DbSet<TEntity> 类型的实体集，将与上下文强耦合，当需求发生变化时，都要对原有代码进行修改，很不利于维护。而封装之后，所有的实体模型都是动态加载到上下文类中的，业务实体与 EntityFramework 能够完全解耦，大大增强系统的可维护性。

EntityFramework封装的常见误区

　　在 EntityFramework 的发展过程中，很多使用者都在抱怨 EntityFramework 性能低下，其实很多时候都是因为对 EntityFramework 没有足够的了解，走进了误区所致。那么，EntityFramework 会有哪些误区呢？这里我列几个我所了解的“坑”，欢迎补充。

错误使用返回类型，不了解 IEnumerable<T> 与 IQueryable<T> 的区别

　　在设计数据访问层的查询API的时候，IEnumerable<T> 和 IQueryable<T> 都可以作为集合类查询结果的返回类型，那么，这两者有什么区别呢？为什么误用的时候会造成致命的性能问题呢？

　　IEnumerable<T> 接口的声明为：　

1 /// <summary>
2 /// 公开枚举数，该枚举数支持在指定类型的集合上进行简单迭代。
3 /// </summary>
4 public interface IEnumerable<out T> : IEnumerable

　　IQueryable<T> 接口的声明为：

1 /// <summary>
2 /// 提供对数据类型已知的特定数据源的查询进行计算的功能。
3 /// </summary>
4 public interface IQueryable<out T> : IEnumerable<T>, IQueryable, IEnumerable

　　在进行查询的时候，IEnumerable<T> 接口接受一个 Func<T, bool> 类型的委托参数： public static IEnumerable<TSource> Where<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate); ，而 IQueryable<T> 接口接受一个 Expression<Func<T, bool>> 类型的表达式参数： public static IQueryable<TSource> Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate); 。

　　正因为 IEnumerable<T> 接受的参数 predicate 数据类型是委托类型，所以这个参数在被调用的时候，就会立即执行查询逻辑，然后将查询的结果保存在内存中，后续的查询逻辑是完全在内存中执行的。而 IQueryable<T> 接受的参数 predicate 数据类型是表达式类型，这个参数会一直往下传递，直到被 IQueryable 中的 IQueryableProvider 类型的 Provider 属性解析成真正的查询语句（如 sql 语句），才传到数据源中进行查询动作。

　　所以，如果查询返回的数据集合很大的时候，使用 IEnumerable<T> 作为返回类型，会将这个数据集合立即加载到内存中，比如在设计 IRepository<T> 的 API 时，设计 IEnumerable<T> GetAll(); ， IEnumerable<T> GetByPredicate(Func<T, bool> predicate); 这种 API ，是非常可怕的，如果一个表中有几十上百万的数据，也同样会把所有数据加载到内存中，可能直接就导致服务器宕机了。即使数据量不大，当并发量上来的时候，也同样会造成极大的性能问题。　　

过早地内存化数据

　　IEnumerable<T> 类型与 IQueryable<T> 类型是支持延迟的，没有真正使用数据之前，不管怎么调用，都不会执行查询，数据还是在数据库内，只有真正使用数据的时候，才会执行查询，把数据本地化到内存中。这样一来，什么时候执行本地化操作（ToArray()，ToList()等操作）就显得非常重要了，如果过早的执行本地化操作，那么就容易造成加载到内存的数据集合过于庞大，记录条数过多，造成性能问题。因此，在进行数据查询的时候，原则上应该按需获取数据，取出的数据集合就尽量的小，字段应尽量少，到数据真正使用的时候，才执行数据内存本地化操作。对于筛选部分字段的需求，linq to entities 的 select 查询匿名结果的查询方式，提供了有力的支持。

导航属性的延迟加载与循环

　　EntityFramework 实体模型的导航属性（即与当前表有外键关系的关联表）通常标记为 virtual，标记为 virtual 之后，相应属性的数据是具有延迟加载的特性的，只有真正用到相应属性的数据时，才会根据外键关系执行相应的查询动作，加载相应的数据。延迟加载的特性，能给系统性能带来优化，因为加载主干实体时只加载主干实体的信息，不会把关联实体的信息都加载进来，关联实体的数据只有用到的时候都会去加载。但也正是因为延迟加载，导航属性的数据是用到一次就执行一次查询动作，加载一次数据，一次还如，如果对于相同实体，需要多次用到同一个导航属性，就会产生多次重复的查询动作来加载导航属性的数据，给系统带来性能问题。例如如下的操作：

　　正确的做法，当需要在循环中使用导航属性时，应在循环之前加载主干实体数据时，把导航属性的数据使用 Include 查询一起加载：

数据查询方式

　　EntityFramework 给我们提供了直接使用实体对象的众多查询 API，如果我们在实现业务的时候，使用直接操作实体对象的方式，同样也会给系统造成性能问题。因为 EntityFramework 每执行一次查询，都会将实体的所有字段取出来，等同于每次都执行“ select * from xxx ” 的查询语句。更可怕的是导航属性的使用，因为导航属性的数据类型通常都定义为 ICollection<T> 或者 ICollection<T> 的派生类型，ICollection<T> 类型是什么？内存集合类型！也就是说，当我们直接调用 entity.NavigationProperties 这样一个导航属性的时候，会将 NavigationProperty 这个关联表的“所有数据”都加载到内存中。想想，如果这个关联表的数据几十上百万的话，那将是多么可怕的性能灾难！！

　　那么，怎样编写数据查询的代码呢，个人认为应该分析场景：

如果查询出来的数据需要进行更新，删除等操作，就使用实体查询的方式。
如果查询出来的数据不需要再存回到数据库中，只是为了业务判断使用，则是按需要使用 Select 进行匿名对象查询的方式来只查询出必要的实体属性。

　　PS：关于 EntityFramework 数据查询的更多内容，欢迎阅读架构系列的《数据查询》篇。

怎样设计 EntityFramework 数据层

　　前面说了那么多误区，那怎样来设计 EntityFramework 的数据访问层 API呢？这个话题在前面的架构系列中也讨论过了，但为了全面了解 OSharp 开发框架，这里不免要添点新料再炒次旧饭。

业务实体模型基类 EntityBase

　　为了能在底层对所有的实体模型类进行统一管理，并规范实体类必要的属性设定，定义了一个如下的实体模型基类 EntityBase<TKey>。为适应不同主键数据类型的需求，定义了一个泛型 Id 类型，在各个实际实体模型中可以设置实体的主键数据类型。

 1 /// <summary>
 2 /// 可持久化到数据库的数据模型基类
 3 /// </summary>
 4 /// <typeparam name="TKey"></typeparam>
 5 public abstract class EntityBase<TKey>
 6 {
 7     protected EntityBase()
 8     {
 9         IsDeleted = false;
10         CreatedTime = DateTime.Now;
11     }
12 
13     #region 属性
14 
15     /// <summary>
16     /// 获取或设置 实体唯一标识，主键
17     /// </summary>
18     [Key]
19     public TKey Id { get; set; }
20 
21     /// <summary>
22     /// 获取或设置 是否删除，逻辑上的删除，非物品删除
23     /// </summary>
24     public bool IsDeleted { get; set; }
25 
26     /// <summary>
27     /// 获取或设置 创建时间
28     /// </summary>
29     public DateTime CreatedTime { get; set; }
30 
31     /// <summary>
32     /// 获取或设置 版本控制标识，用于处理并发
33     /// </summary>
34     [ConcurrencyCheck]
35     [Timestamp]
36     public byte[] Timestamp { get; set; }
37 
38     #endregion
39 
40     #region 方法
41 
42     /// <summary>
43     /// 判断两个实体是否是同一数据记录的实体
44     /// </summary>
45     /// <param name="obj">要比较的实体信息</param>
46     /// <returns></returns>
47     public override bool Equals(object obj)
48     {
49         if (obj == null)
50         {
51             return false;
52         }
53         EntityBase<TKey> entity = obj as EntityBase<TKey>;
54         if (entity == null)
55         {
56             return false;
57         }
58         return Id.Equals(entity.Id) && CreatedTime.Equals(entity.CreatedTime);
59     }
60 
61     /// <summary>
62     /// 用作特定类型的哈希函数。
63     /// </summary>
64     /// <returns>
65     /// 当前 <see cref="T:System.Object"/> 的哈希代码。
66     /// </returns>
67     public override int GetHashCode()
68     {
69         return Id.GetHashCode() ^ CreatedTime.GetHashCode();
70     }
71 
72     #endregion
73 }

业务单元操作接口 IUnitOfWork

　　相比架构系列的数据存储上下文管理，OSharp 的存储上下文进行了简化，OSharp 中的 IUnitOfWork 接口将直接作为上下文类（DbContext的派生类）的一个接口而存在。其中定义了一个默认关闭的 TransactionEnabled 属性开关对“是否开启事务提交”进行管理。在默认的状态下，事务操作是关闭的（与 EntityFramework 的默认开启相反），调用 IRepository 对实体进行增、改、删操作，立即向数据库提交操作，这在进行单步操作的时候，很方便，不用每次都去调用一次 SaveChanges() 操作进行提交。在需要进行事务操作（同时提交多步操作，成功一起成功，失败一起失败）时，则需要将 TransactionEnabled 设置为 true，当调用 IRepository 对实体进行增、改、删操作时，会申请更改，但不会向数据库提交操作，需要在最后手动去调用 UnitOfWork.SaveChanges() 操作进行提交。

 1     /// <summary>
 2     /// 业务单元操作接口
 3     /// </summary>
 4     public interface IUnitOfWork : IDependency
 5     {
 6         #region 属性
 7 
 8         /// <summary>
 9         /// 获取或设置 是否开启事务提交
10         /// </summary>
11         bool TransactionEnabled { get; set; }
12 
13         #endregion
14 
15         #region 方法
16 
17         /// <summary>
18         /// 提交当前单元操作的更改。
19         /// </summary>
20         /// <returns>操作影响的行数</returns>
21         int SaveChanges();
22 
23 #if NET45
24 
25         /// <summary>
26         /// 异步提交当前单元操作的更改。
27         /// </summary>
28         /// <returns>操作影响的行数</returns>
29         Task<int> SaveChangesAsync();
30 
31 #endif
32 
33         #endregion
34     }

实体仓储数据操作接口 IRepository

　　实体仓储数据操作接口 IRepository 的 API，是整个数据层设计的核心。IRepository 接口被定义为“实体类型、主键类型”的双泛型接口，实体类型限定为前面定义的实体基类 EntityBase<TKey> 的派生类，声明如下：

1 interface IRepository<TEntity, TKey> : IDependency where TEntity : EntityBase<TKey>

　　IRepository 中定义了两个属性：

IUnitOfWork 类型的单元操作对象 UnitOfWork，此接口主要用于业务层执行事务操作。
IQueryable<TEntity> 类型的 Entities，作为向业务层开放的 TEntity 实体类型的查询数据源。OSharp 的大部分数据查询，均通过定义 IQueryable<T> 类型的扩展方法来完成。定义为 IQueryable<TEntity> 类型，即能保证 EntityFramework 组件原有的查询自由度，又能阻止业务层使用此数据源进行增、改、删等业务操作，必须调用 IRepository 中规定的 API 才能完成实体的业务操作。

　　在操作 API 上，IRepository 接口主要定义了如下几种 API：

普通增、改、删业务操作 API

　　普通业务操作API主要是对单个或多个实体进行的单个或批量操作API：

 1 /// <summary>
 2 /// 插入实体
 3 /// </summary>
 4 /// <param name="entity">实体对象</param>
 5 /// <returns>操作影响的行数</returns>
 6 int Insert(TEntity entity);
 7 
 8 /// <summary>
 9 /// 批量插入实体
10 /// </summary>
11 /// <param name="entities">实体对象集合</param>
12 /// <returns>操作影响的行数</returns>
13 int Insert(IEnumerable<TEntity> entities);
14 
15 /// <summary>
16 /// 更新实体对象
17 /// </summary>
18 /// <param name="entity">更新后的实体对象</param>
19 /// <returns>操作影响的行数</returns>
20 int Update(TEntity entity);
21 
22 /// <summary>
23 /// 删除实体
24 /// </summary>
25 /// <param name="entity">实体对象</param>
26 /// <returns>操作影响的行数</returns>
27 int Delete(TEntity entity);
28 
29 /// <summary>
30 /// 删除指定编号的实体
31 /// </summary>
32 /// <param name="key">实体编号</param>
33 /// <returns>操作影响的行数</returns>
34 int Delete(TKey key);
35 
36 /// <summary>
37 /// 删除所有符合特定条件的实体
38 /// </summary>
39 /// <param name="predicate">查询条件谓语表达式</param>
40 /// <returns>操作影响的行数</returns>
41 int Delete(Expression<Func<TEntity, bool>> predicate);
42 
43 /// <summary>
44 /// 批量删除删除实体
45 /// </summary>
46 /// <param name="entities">实体对象集合</param>
47 /// <returns>操作影响的行数</returns>
48 int Delete(IEnumerable<TEntity> entities);

针对 DTO 的增、改、删业务操作API

　　在业务层实现对实体的增加，更新操作的时候，如果业务层接收的是 Dto 数据，需要对 Dto 的数据进行合法性检查，再将 Dto 通过数据映射组件 AutoMapper 创建或更新相应类型的实体数据模型 Model，然后再按需求对 Model 的导航属性进行更新，再提交保存。在进行删除操作的时候，需要使用传入的主键 Id 检索相应的实体信息，并检查删除操作的可行性，再提交到上下文中进行删除操作，并删除其他相关数据。在这些针对实体的业务操作中，存在着很多相似的重复代码，这种重复代码的存在，会极大降低系统的可维护性。因此，在数据仓储操作中设计了一组专门针对 Dto 的业务操作API，利用无返回委托 Action<T> 与有返回委托 Func<T, RT> 来向底层传递各实体业务操作的变化点的业务逻辑，以达到对 Dto 业务重复代码的彻底重构。

/// <summary>
/// 以DTO为载体批量插入实体
/// </summary>
/// <typeparam name="TAddDto">添加DTO类型</typeparam>
/// <param name="dtos">添加DTO信息集合</param>
/// <param name="checkAction">添加信息合法性检查委托</param>
/// <param name="updateFunc">由DTO到实体的转换委托</param>
/// <returns>业务操作结果</returns>
OperationResult Insert<TAddDto>(ICollection<TAddDto> dtos, Action<TAddDto> checkAction = null, Func<TAddDto, TEntity, TEntity> updateFunc = null)
    where TAddDto : IAddDto;

/// <summary>
/// 以DTO为载体批量更新实体
/// </summary>
/// <typeparam name="TEditDto">更新DTO类型</typeparam>
/// <param name="dtos">更新DTO信息集合</param>
/// <param name="checkAction">更新信息合法性检查委托</param>
/// <param name="updateFunc">由DTO到实体的转换委托</param>
/// <returns>业务操作结果</returns>
OperationResult Update<TEditDto>(ICollection<TEditDto> dtos, Action<TEditDto> checkAction = null, Func<TEditDto, TEntity, TEntity> updateFunc = null)
    where TEditDto : IEditDto<TKey>;

/// <summary>
/// 以标识集合批量删除实体
/// </summary>
/// <param name="ids">标识集合</param>
/// <param name="checkAction">删除前置检查委托</param>
/// <param name="deleteFunc">删除委托，用于删除关联信息</param>
/// <returns>业务操作结果</returns>
OperationResult Delete(ICollection<TKey> ids, Action<TEntity> checkAction = null, Func<TEntity, TEntity> deleteFunc = null);

数据查询 API

　　一个系统的数据层的所有 API 设计中，看似简单却又最复杂的是数据查询API 的设计，可能的原因如下：

业务需求是未知的，不可预见的，很难设计出能满足各种业务需求的数据查询API
业务需求是多变的，在数据层设计数据查询API，很难保持稳定，往往也要跟随业务进行变更
业务需求需要的数据是千奇百怪的，数据层设置死的API很难满足业务的需求，给多了对系统性能造成影响，给少了又不能满足业务需求

　　基于以上理由，可见在数据层中设计数据查询API，是很难满足业务层对数据的需求的。那怎么办呢？答案就是不把数据查询的API设置死，把数据查询的决定权交给“真正需要数据的地方”，在哪需要数据就在哪查询，需要哪些数据、需要数据的哪一部分，业务层自己说了算，数据层只需要提供一个用于数据查询的“数据源”即可。到这里，IQueryable<T>的一切特性，几乎都是为了满足上面的需求而来的，只需在 IRepository 中对数据层开放一个“只读的” IQueryable<TEntity> 查询数据集即可，不同的数据查询需求，通过设计 IQueryable<T> 的扩展方法来完成。

　　上面定义的 IQueryable<T>查询数据源，能满足大部分数据查询的需求，但某些 EntityFramework 的特定查询需求，还是应该单独定义数据查询API，以更好的保障不丢失 EntityFramework 的数据查询自由度。在这里主要定义了通过主键查找实体、使用 Include 包含指定导航属性的数据查询API：

 1 /// <summary>
 2 /// 获取 当前单元操作对象
 3 /// </summary>
 4 IUnitOfWork UnitOfWork { get; }
 5 
 6 /// <summary>
 7 /// 获取 当前实体类型的查询数据集
 8 /// </summary>
 9 IQueryable<TEntity> Entities { get; }
10 
11 /// <summary>
12 /// 实体存在性检查
13 /// </summary>
14 /// <param name="predicate">查询条件谓语表达式</param>
15 /// <param name="id">编辑的实体标识</param>
16 /// <returns>是否存在</returns>
17 bool ExistsCheck(Expression<Func<TEntity, bool>> predicate, TKey id = default(TKey));
18 
19 /// <summary>
20 /// 查找指定主键的实体
21 /// </summary>
22 /// <param name="key">实体主键</param>
23 /// <returns>符合主键的实体，不存在时返回null</returns>
24 TEntity GetByKey(TKey key);
25 
26 /// <summary>
27 /// 获取贪婪加载导航属性的查询数据集
28 /// </summary>
29 /// <param name="path">属性表达式，表示要贪婪加载的导航属性</param>
30 /// <returns>查询数据集</returns>
31 IQueryable<TEntity> GetInclude<TProperty>(Expression<Func<TEntity, TProperty>> path);
32 
33 /// <summary>
34 /// 获取贪婪加载多个导航属性的查询数据集
35 /// </summary>
36 /// <param name="paths">要贪婪加载的导航属性名称数组</param>
37 /// <returns>查询数据集</returns>
38 IQueryable<TEntity> GetIncludes(params string[] paths);

　　至此，OSharp 的数据层定义基本完成，下篇我们将逐条讲解 EntityFramework 的数据层实现。

开源说明

github.com

　　OSharp项目已在github.com上开源，地址为：https://github.com/i66soft/osharp，欢迎阅读代码，欢迎 Fork，如果您认同 OSharp 项目的思想，欢迎参与 OSharp 项目的开发。

　　在Visual Studio 2013中，可直接获取 OSharp 的最新源代码，获取方式如下，地址为：https://github.com/i66soft/osharp.git

nuget

　　OSharp的相关类库已经发布到nuget上，欢迎试用，直接在nuget上搜索 “osharp” 关键字即可找到
　　

系列导航

本文已同步到系列目录：OSharp快速开发框架解说系列

posted @ 2015-01-29 09:43 郭明锋阅读(14130) 评论(46) 编辑收藏举报

刷新页面返回顶部

郭明锋

程序员只做两件事：让代码奏效和让代码洁净

【开源】OSharp框架解说系列（5.1）：EntityFramework数据层设计

前言

为什么强依赖于EntityFramework

为什么要封装EntityFramework

EntityFramework封装的常见误区

错误使用返回类型，不了解 IEnumerable<T> 与 IQueryable<T> 的区别

过早地内存化数据

导航属性的延迟加载与循环

数据查询方式

怎样设计 EntityFramework 数据层

业务实体模型基类 EntityBase

业务单元操作接口 IUnitOfWork

实体仓储数据操作接口 IRepository

普通增、改、删业务操作 API

针对 DTO 的增、改、删业务操作API

数据查询 API

开源说明

github.com

nuget

系列导航

公告

郭明锋

程序员只做两件事：让代码奏效和让代码洁净

【开源】OSharp框架解说系列（5.1）：EntityFramework数据层设计

前言

为什么强依赖于EntityFramework

为什么要封装EntityFramework

EntityFramework封装的常见误区

错误使用返回类型，不了解 IEnumerable<T> 与 IQueryable<T> 的区别

过早地内存化数据

导航属性的延迟加载与循环

数据查询方式

怎样设计 EntityFramework 数据层

业务实体模型基类 EntityBase

业务单元操作接口 IUnitOfWork

实体仓储数据操作接口 IRepository

普通 增、改、删 业务操作 API

针对 DTO 的 增、改、删 业务操作API

数据查询 API

开源说明

github.com

nuget

系列导航

公告

普通增、改、删业务操作 API

针对 DTO 的增、改、删业务操作API