Is this a workable UnitOfWork with Repository pattern design? I am building a web app with using UOW and Repository pattern. I have seen many different samples and found each one to be different, so not sure which is the correct way to go. I have a basic understanding of both these patterns and I wanted to know if I should keep one UOW implementation for all the tables in my project or keep a separate one as per functionality like for:

public interface IHomeUOW
{
    IGenericRepository&lt;User&gt; Users { get; }
    IGenericRepository&lt;TableA&gt; Table_A { get; }
    IGenericRepository&lt;TableB&gt; Table_B{ get; }
}

public interface IBusinessCaseUOW
{

    IGenericRepository&lt;TableA&gt; Table_A { get; }
    IGenericRepository&lt;TableXYZ&gt; Table_XYZ{ get; }
}


As you can see, TableA is available in both Home UOW as well as a particular business case UOW. One UOW partially implemented as below:

public class UnitOfWork : IUnitOfWork
{

    private readonly ObjectContext _context;
    private UserRepository _userRepository;


    public UnitOfWork(ObjectContext Context)
    {

        if (Context == null)
        {
            throw new ArgumentNullException("Context wasn't supplied");
        }
        _context = Context;
    }

    public IGenericRepository&lt;User&gt; Users
    {
        get
        {
            if (_userRepository == null)
            {
                _userRepository = new UserRepository(_context);
            }

            return _userRepository;
        }
    }
 }


My repositories will be like so

public interface IGenericRepository&lt;T&gt;
    where T : class
    {
        //Fetch records
        T GetSingleByRowIdentifier(int id);             
        T GetSingleByRowIdentifier(string id);          

        IQueryable&lt;T&gt; FindByFilter(Expression&lt;Func&lt;T, bool&gt;&gt; filter);  

        // CRUD Ops
        void AddRow(T entity);
        void UpdateRow(T entity);
        void DeleteRow(T entity);

    }


    public abstract class GenericRepository&lt;T&gt; : IGenericRepository&lt;T&gt;
            where T : class
    {
        protected IObjectSet&lt;T&gt; _objectSet;
        protected ObjectContext _context;

        public GenericRepository(ObjectContext Context)
        {
            _objectSet = Context.CreateObjectSet&lt;T&gt;();
            _context = Context;
        }

        //Fetch Data
        public abstract T GetSingleByRowIdentifier(int id);
        public abstract T GetSingleByRowIdentifier(string id);


        public IQueryable&lt;T&gt; FindByFilter(Expression&lt;Func&lt;T, bool&gt;&gt; filter)
        {
            //
        }

        //CRUD Operations implemented

    }

   public class UserRepository : GenericRepository&lt;User&gt;
   {
         public UserRepository(ObjectContext Context)
         : base(Context)
         {
         }

         public override User GetSingleByRowIdentifier(int id)
         {
          //implementation
         }

         public override User GetSingleByRowIdentifier(string username)
         {
          //implementation
         }
   }


What do you think? If this is not the correct implementation of UOW and Repository pattern for DDD, will it fail as just a bunch of code written to abstract the call to the EF tables?
The UoW pattern has a couple of properties. The UoW will:


track changes to entities, wether that be adding, removing or updating.
coordinate the persisting of these changes in one atomic action. Which also means rolling back if an error occurs.


Since you're using EF, you don't have to implement this stuff, it's done for you. The ObjectContext is actually the UoW object. So unless you plan to switch out Persistence frameworks later on, any additional abstraction will be wasted effort.

I'm guessing you want to make sure your domain isn't aware of how it's persisted. Your domain should only know of the repository interfaces. The repository interfaces are actually part of your domain. The repository implementation though, is part of the persistance layer.

The repository implementation looks OK. I'm only curious about FindByFilter; if you're returning an IQueryable&lt;T&gt; object, you're saying you can query it. OTOH the FindByFilter function already takes an Expression&lt;Func&lt;T, bool&gt;&gt; filter parameter. I'd pick one of the two like the following:

public IEnumerable&lt;T&gt; FindByFilter(Expression&lt;Func&lt;T, bool&gt;&gt; filter)
{
    //
}


or 

public IQueryable&lt;T&gt; FindAll()
{
    //
}


Hope this helps.