Question

I need feedback on designing such a repository, it’ll help me rest at night, seriously…
I have no intention to write tests for web forms, too much overhead involved.
I have no intention to change ORM or database tomorrow, next month or next year and
I need a place to centralize query logic and avoid code duplication. Right?…

public class StuffRepository // no contract, I simply instanciate StuffRepository
{
    // Scope is Per-Request, DI, no abstraction...
    protected StuffDb DbContext = ObjectFactory.GetInstance<StuffDb>();

    // Returns a Stuff, an Entity (EF), no abstraction
    public Stuff Get(Guid id)
    {
        return DbContext.Stuff.FirstOrDefault(s => s.Id == id);
    }
}

I have worked with fully abstracted repositories, MVP architecture on top of web form for individual pages testability and abstracted entities (DTO and domain/model objects). It’s just never ending, it’s never enough, never perfect.

Am I violating every rules, principles and giving birth to an aberration calling this a repository?

If I’d just rename this to StuffDAL, would it suddenly make any sense?

Thanks

Answer 1

I honestly feel the same way about Repositories, finally after reading a ton about it last month, I really got the impression that I have been doing repositories all wrong all along. What I thought was a repository was really just a DAO or DAL, an abstraction to make it it easier to say, “Persistence, give me back my object”, or, “Persistence, hold this object till I want it back later”.

And you know what, I don’t really care what it is called, if it correctly abstracts away what I need, is easy to test, gets the job done, is easy to change.

So, is it a repository as envisioned by Eric Evans with an in-memory store of objects? No, not really, but hey, I won’t turn you in for it.