This module is simple and has no practical effect . In general actual projects are useful database to do persistence, using the database can not use this memorydb module. The reason is that ABP restricts the type of unitofwork to only one (as described earlier), generally using the database must be injected into the efunitofwork. and injected into the efunitofwork can not be injected into the memorydbunitofwork.
memorydatabase: This is a singleton. ABP uses Dictionary<type, object>+lock as the data structure to implement the memory database. It takes the type of entity as key and the entity list as value.
imemorydatabaseprovider: Interface returns MEMORYDATABASE.
Unitofworkmemorydatabaseprovider : Implements the Imemorydatabaseprovider interface by invoking the current of Icurrentunitofworkprovider Unitofwork's database gets memorydatabase.
Memorydbunitofwork: Implements the Iunitofwork interface. The ABP does not implement transactional logic in this module. This class is used only in this module to return the Memorydatabase object.
memoryrepository<tentity, tprimarykey> : Inherit from Abprepositorybase<tentity, Tprimarykey> The crud operation of entity is realized. ( the goods are not thread-safe.) A second argument proving that the module has no practical use )
memoryrepository<tentity> : With memoryrepository<tentity, the tprimarykey> difference is that the entity primary key it supports is the int type.
Back to ABP source Analysis series Articles Directory
ABP Source Code Analysis 28: Abp.memorydb