Using UnitOfWork/Repository pattern in static class/methods
It entirely depends on your implementation of the unit of works members. If the IDataRepository is using something like NHibernate and keeping open persistent connections (which, being part of a unit of work, I presume it might) you will absolutely run into weird database connectivity issues when using a private static member.

The reason for this, is that the static property is shared between all instances of the CustomerService, in your example, so you'll have one of those, and it'll be constructed with "whatever it gets at the time" - for example, the first database connection or session your application opens.  If you have some sort of session per request handling that subsequently disposes of that session, the static class will still hold a reference to it, and you'll have a bad time.

To deal with this problem in some things that "must be" static, there's a cheap little trick you can use - add a static func to some form of resolver or container that you wire up at bootstrapping time:

public class ContainerRegistrationCode
{
    public void RegisterTypesInContainer()
    {
        Kernel.Bind&lt;IUnitOfWork&gt;().To&lt;UnitOfWork&gt;().InRequestScope();
        CustomerService.GetCurrentUnitOfWork = () =&gt; Kernel.GetService&lt;IUnitOfWork&gt;();
    }
}

public class CustomerService
{
    public static Func&lt;IUnitOfWork&gt; GetCurrentUnitOfWork { get; set; }

    public static List&lt;Customer&gt; GetCustomers()
    {
        var currentUnitOfWork = GetCurrentUnitOfWork ();
        currentUnitOfWork.CustomerRepository.Find(t =&gt; t.ID == 123).ToList();
    }
}


This way, you delegate out to a container or something that can manage the lifecycle of the unit of work, and every time you use it in a static context, you call the func which gets whatever the current one is.

It's a bit of a hack, don't use statics, use a good container instead that supports scoping (like Ninject) and you just shouldn't have this problem.