Unit of work--Working Unit (ii)

Review

In the previous article, we made a simple implementation based on the principle of the unit of work, but when the requirements of the project were changed, such as the need to introduce an ORM framework and to be compatible with the current ADO implementation, the previous implementation was unable to meet this requirement.

Let's just say that we're going to refactor the unit of work with the current demand changes. Refactoring unitofwork

First, let's look at the interface extracted from the previously implemented work unit, with the following code:

Public interface iunitofwork
{
    void Registeradd (String sql, params idataparameter[] parameters);                             
    void Registersave (String sql, params idataparameter[] parameters);                           
    void Registerremove (String sql, params idataparameter[] parameters);                          
    void Comit ();
}

Because the requirements need to be compatible with ORM and ADO, and the above interfaces only support ADO, the interface needs to be changed, for example:

Other code omits
void Registeradd (object entity);

Observing the above changes will find that if you want to meet the needs, You need to judge whether it is the operation of ADO or ORM, then there are two different responsibilities, which is obviously unreasonable, but if we will be ADO and ORM or the corresponding data layer class to achieve, it is consistent with a single responsibility, so after the above analysis, you can make further changes to the above interface, the approximate code is as follows:

Other code omits
void Registeradd (object entity, Iunitofworkrepository repository);

According to this idea, the number of iunitofworkrepository will be the same as iunitofwork (there is no commit), one is registration, and the other is the actual operation, so the interface code will be the same as the first change to object, The code is as follows:

Public interface iunitofworkrepository
{
    void Executeadd (object entity);                             
    void Executesave (object entity);                           
    void Executeremove (object entity);
}

With the above changes, you can implement Iunitofwork, the code structure is similar to sqlunitofwork, the difference is that the original is to use a list<sqlentity> to store all the cud operations, But now you have to differentiate between different types of operations, so you need to have containers that store cud, roughly the following code:

public class Unitofwork:iunitofwork {private Dictionary<object, iunitofworkrepository> m_addlist = new Dictio

    Nary<object, iunitofworkrepository> (); Private Dictionary<object, iunitofworkrepository> m_savelist =new dictionary<object, IUnitOfWorkRepository

    > (); Private Dictionary<object, iunitofworkrepository> m_removelist = new Dictionary<object,

    Iunitofworkrepository> (); public void Registeradd (object entity, Iunitofworkrepository repository) {if (!this.m_addlist.containskey (ENT
    ity)) THIS.M_ADDLIST.ADD (entity, repository); The public void Registersave (object entity, Iunitofworkrepository repository) {if (!this.m_savelist.contai
    Nskey (Entity)) THIS.M_SAVELIST.ADD (entity, repository); The public void Registerremove (object entity, Iunitofworkrepository repository) {if (!this.m_removelist.co Ntainskey (Entity)) THIS.M_REMOVELIST.ADD (Entity, RepositoRY); } public void Commit () {using (TransactionScope trans = new TransactionScope ()) {fo Reach (var entity in This.m_addList.Keys) {this.m_addlist[entity].
            Executeadd (entity); } foreach (var entity in This.m_saveList.Keys) {this.m_savelist[entity].
            Executesave (entity); } foreach (var entity in This.m_removeList.Keys) {this.m_removelist[entity].
            Executeremove (entity);
        } trans.complete (); }
    }
}

Here we have the work unit refactoring work done, and then we can derive the implementation based on the iunitofworkrepository of the ADO and ORM. Refactoring schoolrepository

First, let's look at the refactored code:

Class Schoolrepository:irepository, iunitofworkrepository {private idbconnection m_connection = null;

    Private iunitofwork M_UOW = null;
        Public Schoolrepository (idbconnection connection, iunitofwork uow) {this.m_connection = connection;
    THIS.M_UOW = UOW; } public void Add (object entity) {This.m_uow.
    Registeradd (entity, this); } public void Save (object entity) {This.m_uow.
    Registersave (entity, this); } public void Remove (object entity) {This.m_uow.
    Registerremove (entity, this);
        } public void Executeadd (object entity) {School School = entity as School; using (IDbCommand cmd = this.m_connection.
            CreateCommand ()) {cmd.commandtype = CommandType.Text;
            Cmd.commandtext = "Insert School values (@id, @name)"; Cmd. Parameters.Add (New SqlParameter ("@id", school.
            ID)); Cmd. Parameters.Add (New SqlParameter ("@name", school.
            Name)); Cmd.
        ExecuteNonQuery (); }} public void Executesave (object entity) {//code slightly} public void Executeremove (object entity ) {//code slightly}}

IRepository is the basic interface of the data layer, from the code we see the original Cud method has been split into Cud and Executexxx method, Cud method is responsible for invoking the Iunitofwork interface, and executexxx to achieve specific database operations implementation of Iunitofworkrepository based on NHibernate

Look at the code first.

Class Schoolrepository:irepository, Iunitofworkrepository
{
    private iunitofwork m_uow = null;

    Public Schoolrepository (idbconnection connection, iunitofwork UOW)
    {
        this.m_uow = UOW;
    }

    public void Add (object entity)
    {
        this.m_uow. Registeradd (entity, this);
    }

    public void Save (object entity)
    {
        this.m_uow. Registersave (entity, this);
    }

    public void Remove (object entity)
    {
        this.m_uow. Registerremove (entity, this);
    }

    public void Executeadd (object entity)
    {
        SESSIONFACTORY.CURRENTSESSION.ADD (entity);
    }

    public void Executesave (object entity)
    {
        //code slightly
    } public

    void Executeremove (object entity)
    {
        //code slightly
    }
}

From the NHibernate-based implementation, we can see that the Executexxx method is to invoke Nhibernatesession's related methods. End

To this data layer is only bad query, next time will share about the query mode.