How to abstract the ORM-based DATAACCESS layer and how to convert models and data

A colleague asked last day how to replace the database access layer (DataAccess? I am opposed to creating an architecture out of thin air. I advocate that any architecture is based on actual system requirements. But as a reflection, there is no obstacle. As a matter of fact, today, with OO deeply rooted in the hearts of the people, many people still adopt the database access-based architecture. As a result, all business layers are CRUD operations on tables, the complexity of business logic has been dissolved into powerful database modeling. Obviously, this idea based on the database architecture is not conducive to the promotion of OO ideas. We have to admit that in many applications, this database-based architecture is completely normal, but database modeling is required when parsing. This habit is used to build large system applications, or when building scalable system applications, it is extremely unfavorable. I am afraid many people have similar experiences, that is, once the database table has been adjusted, from DataAccess to Business Logic, even the UI must be adjusted accordingly, and the benefits brought by OO are not used at all. Therefore, the Framework Based on Domain Modeling truly utilizes the essence of OO. I have also summarized this before. In Martin Fowler's enterprise application architecture model, I also mentioned three architecture Methods: domain model, transaction script, and table module.

 

I tried to give a rough outline of each layer of my colleagues and draw a sketch to see if there are still problems with scalability and skeleton integrity.

 

UI Layer:

Form {
BizFacade bizFacade;
IAccount currentAccount;
Decimal amount;

ChargeButton. Click (){
BizFacade. Recharge (currentAccount, amount );
}

}

Business logic layer:

BizFacade {
IRecharge recharge;

Void Recharge (IAccount account, decimal amount ){
Recharge. Recharge (account, amount );
}

}

IAccount {
Int Id;
String Name;
String Password;
Decimal CreditLimit;
}

IRecharge {
IDataAccess DataAccess;
Void Recharge (IAccount account, decimal amount );
}

NHRecharge: IRecharge {
IDataAccess DataAccess = new NHDataAccess ();
IMapping <IRecharge, IRechargeEntity> mapping;

Void Recharge (IAccount account, decimal amount ){
IAccountEntity accountEntity = mapping. Convert (account );
AccountEntity. CreditLimit + = amount;
DataAccess. Update (accountEntity );

IRechargeHistoryEntity rechargeHistoryEntity = InstanceHelper. Create ("DefaultRechargeHistoryEntity", new object [] {account. Id, amount });
DataAccess. Add (rechargeHistoryEntity );
}
}

 

Business Model and relational data ing layer:

IMapping <Biz, Entity> {
Biz Convert (Entity entity );
Entity Convert (Biz biz );
}

Database access layer:
IEntity {}

IAccountEntity: IEntity
{
Int Id;
String Name;
String Password;
Decimal CreditLimit;
}

IRechargeHistoryEntity: IEntity {
Int Id;
Int AccountId;
Decimal Amount;
DateTime RechargeDate;
}

IDataAccess {
Object Add (IEntity entity );
Void Update (IEntity entity );
Void Delete (IEntity entity );
IList <IEntity> FindAll ();
IEntity FindByPK (object [] args );
}

NHDataAccess: IDataAccess {
ISessionFactory sessionFactory;

Object Add (IEntity entity ){
Return sessionFactory. Save (entity );
}

Void Update (IEntity entity ){
SessionFactory. Update (entity );
}

Void Delete (IEntity entity ){
SessionFactory. Delete (entity );
}
}

Database layer:

Table Account (
ID: int,
NAME: varchar (50 ),
PASSWORD: varchar (36 ),
CREDITLIMIT: decimal (18, 4 ),
Primary key (ID ));

Table RechargeHistory (
ID: int,
ACCOUNTID: int,
AMOUNT: decimal (18, 4 ),
RECHARGEDATE: datetime,
Primary key (ID ));

IEntity is used at the database access layer as the basis for abstraction between different orm systems. This is not tried and should be acceptable because IEntity is defined based on an attribute of a table field. This architecture sketch is very rough. The biggest feature is the setting of the ing layer between the business model and the relational data. The Convert method provides bidirectional conversion. However, the efficiency of the ing layer needs to be noted. This problem can be avoided if it can be used with the distributed cache. Otherwise, it will be stuck in the quarary of mutual conversion between business models and relational data.