Usage of repository between EF model and code consumer

Question

I have binary data in my database that I'll have to convert to bitmap at some point. I was thinking whether or not it's appropriate to use a repository and do it there. My consumer, which is a presentation layer, will use this repository. For example:

// This is a class I created for modeling the item as is.
public class RealItem
{
    public string Name { get; set; }
    public Bitmap Image { get; set; }
}

public abstract class BaseRepository
{
    //using Unity (http://unity.codeplex.com) to inject the dependancy of entity context.
    [Dependency]
    public Context { get; set; }
}

public calss ItemRepository : BaseRepository
{
    public List<Items> Select()
    {
        IEnumerable<Items> items = from item in Context.Items select item;
        List<RealItem> lst = new List<RealItem>();
        foreach(itm in items)
        {
            MemoryStream stream = new MemoryStream(itm.Image);
            Bitmap image = (Bitmap)Image.FromStream(stream);
            RealItem ritem = new RealItem{ Name=item.Name, Image=image };
            lst.Add(ritem);
        }

        return lst;
    }
}

Is this a correct way to use the repository pattern? I'm learning this pattern and I've seen a lot of examples online that are using a repository but when I looked at their source code... for example:

public IQueryable<object> Select
{
    return from q in base.Context.MyItems select q;
}

as you can see almost no behavior is added to the system by their approach except for hidding the data access query, so I was confused that maybe repository is something else and I got it all wrong. At the end there should be extra benifits of using them right?

Update: as it turned out you don't need repositories if there is nothing more to be done on data before sending them out, but wait! no abstraction on LINQ query? that way client has to provide the query statements for us which can be a little unsafe and hard to validate, so maybe the repository is also providing an abstraction on data queries? if this is true then having a repository is always an essential need in project architecture!! however this abstraction can be provided by using SQL stored procedures. what is the choice if both options are available?

Answer 1

Yes, that's the correct way: the repository contract serves the application needs, dealing ony with application objects.

The (bad)example you are seeing most of the time couples any repository implementation to IQueryable which may or may be not implemented by the underlying orm and after all it is an implementation detail.

The difference between IQueryable and IEnumerable is important when dealing with remote data, but that's what the repository does in the first place: it hides the fact you're dealing with a storage which can be remote. For the app, the repository is just a local collection of objects.

Update The repository abstracts the persistence access, it makes the application decoupled from a particular persistence implementation and masks itself as a simple collection. This means the app doesn't know about Linq2Sql, Sql or the type of RDBMS used, if any. The app sends/receives objects from the repo, while the repo actually persists or loads objects. The app doesn't care how the repo does it.

I consider the repository a very useful pattern and I'm using it in every project, precisely because it marks the boundry between the application (as the place where problems and solutions are defined and handled) and storage/persistence where data is saved.