UOW and repositories in an Entity Framework asp.net application - asp.net

Question

I have just started reading up on using the repository and unit of work patterns. I am currently trying to use it with Entity Framework in an asp.net web forms application. I do however have a question which I am not sure if I would be able to explain in an easy way.
From what I understand a unit of work is used to encapsulate a business transaction. From the examples I have seen a uow is used in the following manner
businessMethod1()
{
uow u = new uow(); //instantiate unit of work
repository1 rep1 = new repository1(uow); //instantiate repository1
repository2 rep2 = new repository2(uow); //instantiate repository1
rep1.dowork();
rep2.dowork();
u.save(); //save the changes made to the database. (effectively saving changes made
//in both repository classes
}
Now suppose I have a businessMethod2() which is similar to the method described above. Suppose I want to use businessMethod1() from within businessMethod2() what would be the best practice. I would want to share the unit of work so should I pass it as an argument? i.e change the method mentioned above to
businessMethod1(uow u)
{
bool isNew = false;
if (u == null)
{
u = new uow();
isNew = true;
}
repository1 rep1 = new repository1(uow); //instantiate repository1
repository2 rep2 = new repository2(uow); //instantiate repository1
rep1.dowork();
rep2.dowork();
if (isNew)
u.save(); //save the changes made to the database.
}
Is this a proper way of working with this?
I was thinking a better way would be to use a singleton uow. On every page request a new instance of the uow is created and is shared by all the business methods. On a new request a different instance is created. Using a singleton uow would mean i wont have to pass it to any of my business methods and can at the same time share it b/w all my business methods.
Are there any drawbacks of doing this? Also is there a better way to implement this?

Answer 1

One way to solve this problem is to use Dependency Injection. Usually constructor injection is used along side a single point of entry to resolve dependencies.
public class MyBusinessService
{
public MyBusinessService(Repository1 repository1, Repository2, uow u)
{
// assign the params to fields
}
public void businessMethod1()
{
}
public void businessMethod1()
{
}
}
There are many popular DI frameworks out there. Pick what you think works for you.

Answer 2

This is about usage of UoW. If you place usage of UoW into BusinessMethod1 you are saying that it is top level business abstraction (business facade). It should probably not be used by other business operation because it would break its "top level". So if you need to use the logic from BusinessMethod1 in another BusinessMethod2 it is not correct approach to add logic making decision about UoW existence - that breaks separation of concerns. BusinessMethod should handle your application logic not UoW creation. Simplest solution is to refactor your BusinessMethod1 and expose shared functionality as a new method without any dependency on UoW:
public void BusinessMethod1()
{
uow u = new uow();
DoSomeWork();
u.save();
}
private void DoSomeWork()
{
repository1 rep1 = new repository1(uow); //instantiate repository1
repository2 rep2 = new repository2(uow); //instantiate repository1
rep1.dowork();
rep2.dowork();
}
Sure this is only very simple example because your methods still don't follow separation of concerns - they do both logic and object creation. You should handle UoW and repositories creation elsewhere and pass created objects inside. You can use approach mentioned by #Eranga but this refactoring will be still applicable if your method2 wants to call something from method1.
This refactoring approach can be modeled also as low level business services and business facade but it is needed only in big projects. In small projects you can also move interaction with UoW to your "controller" (probably code behind in web forms) because the controller drives application logic and it knows what business methods it wants to call in single unit of work.