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

Question

Having built a small application using the Unit of Work/Repository pattern, I am struggling to understand how to use this properly within my business layer. My application h

Answer 1

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.

Answer 2

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.