在前一篇博文中，突发奇想地用文件存储实现了oauth refresh token的持久化。在这篇博文中，我们将面对现实地将文件存储改为数据库存储。既然软件开发中唯一不变的就是变化本身，那我们主动求变，用变化来验证代码的设计是否能随机应变。
之前使用文件存储的架构是这样的：
- Presentation层-WebAPI：CNBlogsRefreshTokenProvider
- Application层-接口：IRefreshTokenService
- Application层-实现：RefreshTokenService
- Domain层-实体：RefreshToken
- Repository层-接口：IRefreshTokenRepository
- Repository层-实现：FileStorage.RefreshTokenRepository
依赖关系是这样的：
- Presentation层的CNBlogsRefreshTokenProvider -> Application层的接口IRefreshTokenService + Domain层的实体RefreshToken。
- Application层的实现RefreshTokenService -> Repository层的接口IRefreshTokenRepository + Domain层的实体RefreshToken。
- Repository层的实现FileStorage.RefreshTokenRepository -> Domain层的实体RefreshToken。
对于这样的分层架构，要将文件存储改为数据库存储，看上去似乎很简单——只需基于数据库存储，使用相应的ORM工具（比如EF），实现IRefreshTokenRepository接口，然后将之注入，其它地方无需更改1行代码。
当我们悠哉悠哉地去写IRefreshTokenRepository接口的实现Database.RefreshTokenRepository的代码时，突然发现有些不对劲。
之前基于文件存储的FireStorage.RefreshTokenRepository的代码是这么实现的（为了简化问题，我们只看查询部分的实现）：
public class RefreshTokenRepository : IRefreshTokenRepository
{
private List<RefreshToken> _refreshTokens;
public RefreshTokenRepository()
{
//...
}
public async Task<RefreshToken> FindById(string Id)
{
return _refreshTokens.Where(x => x.Id == Id).FirstOrDefault();
}
}
现在基于Entity Framework写Database.RrefreshTokenRepository的实现代码时，也要写同样的LINQ查询代码（下面代码中的加粗部分）：
public class RefreshTokenRepository : IRefreshTokenRepository
{
public RefreshTokenRepository()
{
}
public async Task<RefreshToken> FindById(string Id)
{
using (var context = new OpenApiDbContext())
{
return context.Set<RefreshToken>()
.Where(x => x.Id == Id).FirstOrDefault();
}
}
}
虽然只是1行代码的重复，但是越看越不对劲。假如复杂一些的项目，有很多LINQ查询时，有多种持久化方式，还有针对单元测试的mock，这将会造成大量重复代码。
当一个变化会引发重复代码时，错的肯定不是变化本身，而是代码本身——代码的设计有问题。现在重复代码就在眼前，现在不解决，更待何时。
要解决重复代码问题， 先要看一下相同（重复）代码之前的不同之处在哪里，然后在表面上看起来的不同之处找出共同点，用接口封装不同。这就是代码设计中的求同存异法（注：实际没有这个方法，写这篇博文时臆造出来的）。
回到上面的代码，.Where(x => x.Id == Id).FirstOrDefault(); 之前的不同之处是 _refreshTokens 与 context.Set<RefreshToken>()，前者的类型是 List<RefreshToken>，后者的类型是 System.Data.Entity.DbSet ，这2个不同有什么共同之处呢？
在Visual Studio中按F12键向上求索，终于找到了1个共同之处，那就是IQueryable——DbSet实现了IQueryable接口，List可以转换为IQueryable（通过AsQueryable方法）。既然找到了共同之处，那我们就可以通过它消灭重复代码，将2个RefreshTokenRepository变成1个RefreshTokenRepository。
public class RefreshTokenRepository : IRefreshTokenRepository
{
private IQueryable<RefreshToken> _refreshTokens;
public RefreshTokenRepository()
{
}
public async Task<RefreshToken> FindById(string Id)
{
return _refreshTokens.Where(x => x.Id == Id).FirstOrDefault();
}
}
上面的代码实现了求同——从2个不同之处找到了共同之处，但如何存异呢？也就是如何根据不同的持久化存储方式给上面代码中的_refreshTokens成员变量赋值呢？这又带来了_refreshTokens的求同存异问题。
这时你有没有想到，有一个东西就是为求同存异而生，它就是——接口（Interface）。
那我们就引入一个接口来解决_refreshTokens的赋值问题，这个接口暂且叫做IUnitOfWork吧。IUnitOfWork的代码如下：
public interface IUnitOfWork : IDisposable
{
IQueryable<TEntity> Set<TEntity>() where TEntity : class;
}
于是RefreshTokenRepository就可以通过IUnitOfWork接口给_refreshTokens赋值：
public class RefreshTokenRepository : IRefreshTokenRepository
{
private IQueryable<RefreshToken> _refreshTokens;
public RefreshTokenRepository(IUnitOfWork unitOfWork)
{
_refreshTokens = unitOfWork.Set<RefreshToken>();
}
public async Task<RefreshToken> FindById(string Id)
{
return _refreshTokens.Where(x => x.Id == Id).FirstOrDefault();
}
}
接着我们针对文件存储的持久化方式，实现一个FileStorageUnitOfWork：
public class FileStorageUnitOfWork : IUnitOfWork
{
public IQueryable<TEntity> Set<TEntity>() where TEntity : class
{
return ReadFromFile<TEntity>().AsQueryable<TEntity>();
}
private IList<TEntity> ReadFromFile<TEntity>()
{
IList<TEntity> entities = null;
var jsonFilePath = HostingEnvironment.MapPath(string.Format("~/App_Data/{0}.json", typeof(TEntity)));
if (File.Exists(jsonFilePath))
{
var json = File.ReadAllText(jsonFilePath);
entities = JsonConvert.DeserializeObject<List<TEntity>>(json);
}
if (entities == null) entities = new List<TEntity>();
return entities;
}
}
再接着针对数据库存储的持久化方式，基于Entity Framework实现一个EfUnitOfWork（EF的映射配置省略）：
public class EfUnitOfWork : DbContext, IUnitOfWork
{
public new IQueryable<TEntity> Set<TEntity>() where TEntity : class
{
return base.Set<TEntity>();
}
}
最后，想用什么持久化方式，就用IOC容器（比如Unity）注入对应的UnitOfWork。
要用文件存储，就注入FileStorageUnitOfWork：
container.RegisterType<IUnitOfWork, FileStorageUnitOfWork>(new HttpContextLifetimeManager<IUnitOfWork>());
要用数据库存储，就注入EfUnitOfWork：
container.RegisterType<IUnitOfWork, EfUnitOfWork>(new HttpContextLifetimeManager<IUnitOfWork>());
这样，我们就可以轻松地将oauth refresh token的持久化方式从文件存储换到数据库存储，从数据库存储换到文件存储。或者哪天突发奇想换到NoSQL，也是手到擒来的事。
写了这么多废话，实际上只是为了一个接口的粉墨全场——IUnitOfWork。为了在持久化方式变化的情况下，保持Repository层的不变，我们引入了IUnitOfWork接口，让Repositroy依赖IUnitOfWork，将持久化方式封装在IUnitOfWork的实现中，从而解决了持久化方式变动带来的重复代码问题。再次实际体会了：小接口，大力量。
【附】
变化之后的架构如下：
- Presentation层-WebAPI：CNBlogsRefreshTokenProvider
- Application层-接口：IRefreshTokenService
- Application层-实现：RefreshTokenService
- Domain层-实体：RefreshToken
- Repository层-接口：IRefreshTokenRepository
- Repository层-实现：RefreshTokenRepository
- UnitOfWork层-接口：IUnitOfWork
- UnitOfWork层-实现：FileStorageUnitOfWork与EfUnitOfWork