I'm using the Repository pattern in my application right now. It is a console-based batch processing tool. Essentially I need the repository to be able to randomly access the data. The trouble I am having is that my data needs to be:

  1. read in once (from flat-file)
  2. accessed randomly from the repository
  3. written out once.

I handle this in the code by using a guard clause to see if the records have been accessed yet, and if not then read them in. A simple example below.

public IUnit GetById(int id)
    if (!ReadIn)
    return _listOfUnits[id];

My question is this: Would it be a bastardization of the Repository pattern if I had a module that ran before the rest of my program to read the data into the repository, and another module that ran afterward to write data out of the repository? Is this an anti-pattern? Is there a better pattern to suit my situation?


  • Just IMO, reading all object lazily like that might force the callers of GetById() to deal with more problems than they're equipped to handle. Also, the time-guarantee of that function is not very good. (It could run in the GUI thread, since it does very little, unless it was loading stuff...)
    – Macke
    Mar 31, 2011 at 20:18

3 Answers 3


The whole point of the repository pattern is to allow you to abstract away the implementation behind a generic interface. You can use whatever method works best for your situation, and if you want to change it later, it shouldn't affect the rest of your application.

Use whatever implementation works best (and is the easiest to understand and maintain).

  • Fair enough, I had thought as much. Thought I would ask to see if there was an angle I was missing! Mar 31, 2011 at 17:09

I would consider combining Unit of Work pattern with Repository pattern.

The unit of work is similar to a transaction (and often wraps one) and would be responsible for telling the repository to load data initially and save it at the end.

  • No database though, only flat files. I'm not seeing how the UnitOfWork applies ... Mar 31, 2011 at 17:09
  • @Jefrey Cameron - The Unit Of Work pattern corresponds to the commit and rollback operations. Qes is right, since you're not actually committing anything to the file until you save it, it kind of corresponds to a unit of work. If the program crashed in the middle, you'd lose your data, right? That would be like rolling back. Mar 31, 2011 at 17:33
  • @Jeffery Cameron: If you are reading everything once, doing a bunch of work, and then writing things once, that's a unit of work. It's exactly a transaction, just not a database transaction. Mar 31, 2011 at 17:33

I think that the best code is what works (and is clean, testable, maintainable of course), regardless of whether it faithfully implements some pattern or not.

If you need to use most or all of the records during processing, to me it sounds perfectly fine to read all data eagerly before and save it after. Lazy loading always complicates the code, it may introduce concurrency problems etc. So it is only worth using if it can actually save execution time, when the data is often not needed at all, or needed only late in the process, or it can be loaded in little portions to improve startup time.

Moreover, AFAIK there is nothing in the Repository pattern mandating lazy loading of items - you are free to load them however it fits you behind the curtain. As for loading and saving items by a different external module, this may indeed break the encapsulation of the interface, but I believe it is possible to move those modules behind the repo interface as well - it can have init and shutdown methods.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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