I couldn't find a single example about repository pattern using something else then a database.

My goal is to have a global static repository that stores some objects in memory. I don't want it to be a singleton with it's Instance property because it doesn't have any special function but Add/Removoe... just like a repository.

So let's assume I want to keep a collection of object converters somewhere in memory. Am I misusing the repository pattern for this (becuase it seems to be the most suitable solution here)? Or do you call it something else and repository is reserved only for databases or other storage types?

public static ConvertersRepository : IConvertersRepository
    // this is the actual collection
    private static IList<IObjectConvereter> _converters = new List<IObjectConvereter>;
    public static void AddObjectConverter(IObjectConvereter...) {}
    public static IObjectConvereter GetObjectConverter(...) {}
  • Is this just a cache, then? – MetaFight Nov 9 '15 at 21:06
  • @MetaFight mhmm I didn't think of it like that but I don't think so, to me objects in a cache would expire, these objects don't. They're just there waiting to be retrieved and used. Initialily there would be a set of default objects (converters) to start with. – t3chb0t Nov 9 '15 at 21:09
  • @t3chb0t items in a cache do not necessarily have to expire. – user22815 Nov 9 '15 at 21:18
  • I guess if they don't expire (outside of program termination) you could call this a simple in-memory database and thereby justify the use of the term "repository pattern". But it's all semantics. – Ixrec Nov 9 '15 at 21:21
  • 2
    Saying it's all semantics somehow undermines the purpose of Programmers ;-] many questions would fall into this category. event or trigger, message or notice, repository or cache, collection or list and so on. – t3chb0t Nov 9 '15 at 21:37

Disclaimer: I looked up the Repository pattern because I've never heard of it by this name before. To me it looks just like a standard wrapper around the persistence/database layer.

It's common to use wrappers around data access and change the implementation behind the wrapper as the project progresses, and some of the early implementations are often not even persisting the data on disk. So for the pattern I know, which I think is the Repository pattern you speak of, it doesn't matter if the data is stored in a database. All that matters is that it could be stored in a database - but that's implementation. Still, the pattern strongly implies persistence, so I wouldn't say you're really using the Repository pattern here.

Your question has two parts. One part is the question if what you're doing is the Repository pattern, the other is if it's fine to call something XyzRepository if it doesn't implement the Repository pattern.

That second question depends on the entirety of your or your company's codebase. I've seen many codebases with plenty of classes named ...Repository that had nothing to do with persisting something on disk. In a general case it's perfectly normal to call a class that is a repository of xyz XyzRepository. And what your question describes certainly is a repository of converters. However (!), if in a specific case you have a codebase where all other classes that are named ...Repository are wrapping persistent storage, then using the name for something that doesn't offer persistency can be confusing or misleading, and therefore should be avoided.

A list of alternative but not necessarily better names: Converters ConvertersPool ConvertersHub ConvertersCollection ConvertersStore ConvertersManager

  • They key to your answer is "it strongly implies persistence." Since the OP has essentially built a cache this answer is correct. The repository pattern is not just about persisting to a database. Any sort of persistence that acts like a collection of objects can benefit from this pattern, regardless of implementation. – Greg Burghardt Nov 10 '15 at 21:36

Data source doesn't mean database. You could perfectly have a Repository that talks to a remote service instead of a DB. The important thing is that from a client code perspective, the Repository looks like it's a collection you can look into, add to or remove from. It's a useful abstraction.

From Martin Fowler's PoEAA :

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection

There's probably a lot to say about the static nature of your Repository, notably because a static method can't implement an interface, but in spirit I think it does satisfy the contract.

  • Yes, I've noticed the bug with the static and the interface later too ;-] it doesn't make any sense of course and wouldn't compile either, I just forgot to remove the interface after pasting my current solution and adding the static keyword. – t3chb0t Nov 10 '15 at 10:20

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.