2

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?

Improve this question

3 Answers 3

Reset to default
1

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).

Improve this answer
4
  • 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? Commented Apr 2, 2012 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/… Commented Apr 2, 2012 at 6:47
  • but how would i hide the data access technology? Commented Apr 3, 2012 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. :) Commented May 31, 2012 at 16:54
0

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.

Improve this answer
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.