Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 select q;
}

as you can see no behavior is added to the system by their approach, 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?

share|improve this question
add comment

3 Answers 3

I would leave the Image field in your entity as byte[] and add a new property called ImageObject which returns the Image byte[] into an appropriate Image object.

public class RealItem
{
    public string Name { get; set; }
    public byte[] Image { get; set; }
    public Bitmap ImageObject
    {
        get
        {
            using(MemoryStream stream = new MemoryStream(this.Image))
            {
                 Bitmap image = (Bitmap)Image.FromStream(stream);
                 return image;
            }
        }
    }
}

Feel free to improve this by adding some sort of caching functionality to convert the image bytes once instead of each call (and renew the image object only if bytes changed).

share|improve this answer
    
so what about repository pattern? don't you need it? why would you do it in setter which is not responsible for converting types. beside, how would you return a list of real objects if there is no repository to hide the data access technology? –  jim Apr 2 '12 at 5:41
    
EF is your repository pattern. See this interview of Ayende who is working on nHibernate (similar to EF): community.devexpress.com/blogs/seth/archive/2011/03/09/… –  user2567 Apr 2 '12 at 6:47
    
but how would i hide the data access technology? –  jim Apr 3 '12 at 17:42
    
If you want to wrap up the context-access in a repository, here is a link worth reading. Generally, I'd stick to a non-generic interface with generic methods, easy and flexible. :) –  Patryk Ćwiek May 31 '12 at 16:54
add comment

There are several potential benefits of a repository pattern, especially if you set it up as an interface that can easily use dependency injection. I noticed in your example only the context is being injected, you might change it to allow the repository itself to be injected.

  • It can aid in unit testing the other layers by isolating the data access to allow you to easily mock the repository so that your unit tests are not dependent on the repository.
  • It can be used to enforce certain methods and consistency of access to your repository. For example in a multi-tenancy application you may want to ensure that the Tenant Id is always passed rather than allowing direct access to the context to help enforce security.
  • It reduces duplication of code in your other layers.
  • It decouples the repository from your other layers so that the repository itself can be more easily changed at a later time.

Some of the same objectives can be met with a business logic service layer, it depends on the needs of your application.

share|improve this answer
add comment

That is exactly the value add that a Repository can give above and beyond the standard crud operations. However, I would take advantage of deferred operations. Instead of List, return IEnumerable (or even IQueryable which will allow the consumer to filter it even more) and instead of foreaching return the realitem from the selector like so

public IQueryable<RealItem> Select()
{
   return Context.Items.Select(item=>
   {
      Bitmap image;
      using(MemoryStream stream = new MemoryStream(item.Image))
      {
         image = (Bitmap)Image.FromStream(stream);
      }
      return new RealItem{Name=item.Name, Image=image};

   });
}

The other option is like someone else mentioned, provide a second property on RealItem that does the conversion from bytearray to bitmap for you.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.