What is the correct way to use Unit of Work/Repositories within the business layer?

左心房为你撑大大i 提交于 2019-11-30 20:30:59

Looks to me like you've almost got it. In our new server stack I have this setup:

WCF Service Layer  --> just returns results from my Business Layer

My business layer is called, creates a unitofwork, creates the respository
Calls the respository function
Uses AutoMapper to move returned results into a DTO

My repository gets the query results and populates a composite object.

Looks almost like what you've got there. Though we use Unity to locate what you call the business layer. (we just call it our function processor)

What I would highly suggest, though, is that you do NOT keep the UnitOfWork at the class level. After all each descreet function is a unit of work. So mine is like this (the names have been changed to protect the innocent):

        using ( UnitOfWorkScope scope = new UnitOfWorkScope( TransactionMode.Default ) )
        {
            ProcessRepository repository = new ProcessRepository(  );
            CompositionResultSet result = repository.Get( key );
            scope.Commit( );

            MapData( );
            return AutoMapper.Mapper.Map<ProcessSetDTO>( result );
        }

We also had a long discussion on when to do a scope.Commit and while it isn't needed for queries, it establishes a consistent pattern for every function in the application layer. BTW we are using NCommon for our repository/unitofwork patterns and do not have to pass the UoW to the repository.

Your IUnitOfWork implementation contains all repositories.

Your IUnitOfWork is injected into your presentation layer like mvc controller.

Your IUnitOfWork is injected into mvc controller.

Your IRepository is injected into your UnitOfWork implementation.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!