Is there anything wrong with having a few private methods exposing IQueryable<T> and all public meth

Posted by Nate Bross on Stack Overflow See other posts from Stack Overflow or by Nate Bross
Published on 2010-05-25T20:36:50Z Indexed on 2010/05/25 20:51 UTC
Read the original article Hit count: 197

Filed under:
|
|
|

I'm wondering if there is a better way to approach this problem. The objective is to reuse code.

Let’s say that I have a Linq-To-SQL datacontext and I've written a "repository style" class that wraps up a lot of the methods I need and exposes IQueryables. (so far, no problem).

Now, I'm building a service layer to sit on top of this repository, many of the service methods will be 1<->1 with repository methods, but some will not. I think a code sample will illustrate this better than words.

public class ServiceLayer 
{
    MyClassDataContext context;
    IMyRepository rpo;

    public ServiceLayer(MyClassDataContext ctx) 
    { 
        context = ctx; 
        rpo = new MyRepository(context);   
    }

    private IQueryable<MyClass> ReadAllMyClass()
    {
        // pretend there is some complex business logic here
        // and maybe some filtering of the current users access to "all"
        // that I don't want to repeat in all of the public methods that access
        // MyClass objects.
        return rpo.ReadAllMyClass();
    }

    public IEnumerable<MyClass> GetAllMyClass()
    {
        // call private IQueryable so we can do attional "in-database" processing
        return this.ReadAllMyClass();
    }

    public IEnumerable<MyClass> GetActiveMyClass()
    {
        // call private IQueryable so we can do attional "in-database" processing
        // in this case a .Where() clause
        return this.ReadAllMyClass().Where(mc => mc.IsActive.Equals(true));
    }

    #region "Something my class MAY need to do in the future"
    private IQueryable<MyOtherTable> ReadAllMyOtherTable()
    {
        // there could be additional constrains which define
        // "all" for the current user
        return context.MyOtherTable;
    }

    public IEnumerable<MyOtherTable> GetAllMyOtherTable()
    {
        return this.ReadAllMyOtherTable();
    }

    public IEnumerable<MyOtherTable> GetInactiveOtherTable()
    {
        return this.ReadAllMyOtherTable.Where(ot => ot.IsActive.Equals(false));
    }
    #endregion

}

This particular case is not the best illustration, since I could just call the repository directly in the GetActiveMyClass method, but let’s presume that my private IQueryable does some extra processing and business logic that I don't want to replicate in both of my public methods.

Is that a bad way to attack an issue like this? I don't see it being so complex that it really warrants building a third class to sit between the repository and the service class, but I'd like to get your thoughts.

For the sake of argument, lets presume two additional things.

  1. This service is going to be exposed through WCF and that each of these public IEnumerable methods will be calling a .Select(m => m.ToViewModel()) on each returned collection which will convert it to a POCO for serialization.
  2. The service will eventually need to expose some context.SomeOtherTable which wont be wrapped into the repository.

© Stack Overflow or respective owner

Related posts about c#

Related posts about .NET