Repository with no interface and no abstraction = aberration?

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 cont开发者_Python百科ract, 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

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.

To me, a repository is here to give you global persistence over your data including caching not to fetch once again your db for instance. It is also something function dedicated, other than CRUD. Whereas, the DAL is giving you an access to the database who is the only responsible for making the data peristent over different calls from your application and is usually restricted to CRUD call to the Database

From what you wrote you are definitely in the second choice. With some other things added, I might not be so strict.

but have a look here and you'll see that the difference between both is all relative.

AS to the will not to use interface, I do not recommand it. So useful to have added a few lines, after a while...