本文详细分析了ABP框架下MemoryDB模块的使用场景与限制，指出其在实际项目中的局限性，并探讨了与数据库持久化相关的替代方案，如使用EF UnitOfWork。同时，介绍了MemoryDB模块内部结构与实现细节，包括单例MemoryDatabase、IMemoryDatabaseProvider及MemoryDbUnitOfWork等组件，以及它们在模块设计中的角色与功能。最后，整理了ABP源码分析系列文章的目录链接。
这个模块简单，且无实际作用。一般实际项目中都有用数据库做持久化，用了数据库就无法用这个MemoryDB 模块了。原因在于ABP限制了UnitOfWork的类型只能有一个(前文以作介绍)，一般用了数据库的必然要注入efUnitOfWork. 而注入了efUnitOfWork就不能在注入MemoryDbUnitOfWork了。
MemoryDatabase：这是一个单例。ABP通过Dictionary<Type, object>+lock作为数据结构来实现内存数据库。其以entity的类型作为key,以entity list为value。
IMemoryDatabaseProvider： 接口返回MemoryDatabase。
UnitOfWorkMemoryDatabaseProvider ： 实现IMemoryDatabaseProvider接口，通过调用ICurrentUnitOfWorkProvider的current UnitOfWork的Database获取MemoryDatabase。
MemoryDbUnitOfWork：实现IUnitOfWork接口。ABP在这个本模块中并没有实现事务逻辑。这个类在此模块中只用于返回MemoryDatabase对象。
MemoryRepository<TEntity, TPrimaryKey> : 继承自AbpRepositoryBase<TEntity, TPrimaryKey>，实现了Entity的CRUD操作。（这货居然不是线程安全的。证明这个模块无实际用途的第二个论点）
MemoryRepository<TEntity> ： 其与MemoryRepository<TEntity, TPrimaryKey>差异就在于其支持的Entity主键是int类型。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
