Some Issues about Rob Conery's repository pattern !

Answer 1

Not a dodge to your question, but it's ultimately up to you to decide how your repository would work.

The high level premise is that your controller would point to some repository interface, say IRepository<T> where T : IProduct. The implementation of which could do any number of things---load up your whole database from disk and store in memory and then parse LINQ expressions to return stuff. Or it could just return a fixed set of dummy data for testing purposes. Because you're banging away on an repository interface, then you could have any number of concrete implementations.

Now, if you're looking for a critique of Rob's specific implementation, I'm not sure that's germaine to SO.

Answer 2

While it's possible to populate part of an object based on a query of a subset of the columns for that object using a query (which has nothing to do with the repository pattern), that's not how things are "normally" done.

If you want to return a subset of an object, you generally create a new class with just that subset of properties. This is often (in the MVC world view) referred to as a View Model class. Then, you use a projection query to fill that new class.

You can do all of that whether you are using the repository pattern or not. I would argue there is no conflicting overlap between the two concepts.

Answer 3

DeferringTheLoad

Remember that IQueryable defers all the loading up to the last responsible moment. you probably won't have to load all the data using the LINQ operators to get the data you want. ; )

EDIT: respecting the dependency in domain classes in views, I will say NO. use a ViewModel pattern for this. it's more maintainable, you could use AutoMapper to avoid the mapping problems, and are very flexible in composite views scenarios : )

UPDATE: According to the new question...The answer is yes you can. just as Rob Conery says, use projection ; ):

var query = from p in DataContext.Persons}
select new Persons
{
  firstname = p.firstname,
  lastname = p.lastname
});

Answer 4

I decided to use sort of programming against Interfaces

I'll build my Model based on Interfaces and then I'll expand L2S classes to implement these interfaces. Then in my repository I'll return list of Interface rather than list of my model class.

E.G.

this is the Interface:

public interface IProduct
{
    int ID { get; set; }
    string Name { get; set; }
    .
    ..
    ...
    string Notes { get; set; }
}

then my model will look like this :

public class Product:IProduct
{

    #region IProduct Members

    public int ID { get; set; }
    public string Name{ get; set; } 
    .
    ..
    ...
    public string Notes { get; set; }
}

And because the "Linq To Sql" classes are partials I'll expand them to implement this Interface:

public partial class Product:IProduct
{

    #region IProduct Members
    .
    ..
    ...
    // if there is any deference between L2S class and my Model class should considered here
    #endregion
}

then my Repository will return IQueryable<IProduct> rather than IQueryable<Product> like this :

public class ProductRepository
{
    public IQueryable<IProduct> GetAllProducts()
    {
        ...
        ....
        var list = from p in db.Products
                   select (IProduct)p;
        return list;
    }
}

So please tell me your opinion is this will be fine ?? Or you prefer something better ??.

Answer 5

Yes, it's possible if you're using Linq to SQL. All you need to do is use Projection to pull out the data you want into an object of your choosing. You don't need all this decoration with interfaces and whatnot - if you use a model specific to a view (which it sounds like you need) - create a ViewModel class.

Let's call it ProductSummaryView:

public class ProductSummaryView{
   public string Name {get;set;}
   public decimal Price {get;set;}

}

Now load it from the repo:

var products= from p in _repository.GetAllProducts
              where p.Price > 100
              select new ProductSummaryView {
                  Name=p.ProductName,
                  Price=p.Price

              }

This will pull all products where the price > 100 and return an IQueryable. In addition, since you're only asking for 2 columns, only two columns will be specified in the SQL call.