4

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

maxbeaudoin
  • 6,546
  • 5
  • 38
  • 53
  • 3
    If you never intend to test or change the code then presumably it is perfect as it is. But who ever intends to change their code? Changes are forced upon us - and we need to be ready. Ask yourself the question why aren't I building this 'properly'. Is it just because you can't be bothered or are their other constraints? If the objective is to cut out all the unnecessary noise in your code for example - maybe look at a mirco-orm instead? But do unit test - you will thank yourself later. – James Gaunt Jul 26 '11 at 15:39
  • It's just not in my intentions to swap ORMs or databases. I don't see why I couldn't change code here? Unless I don't understand? There are reasons why I simply can't write tests and abstract everything. First, to test web forms requires additional service layers, to write and maintain tests requires additional time, to abstract requires additional time, to DI abstracted components requires additional time and is quite awful in a web form's Page's constructor or on_init event... I just deliver projects on a strict schedule and can't be involved emotionally or personally, it has to be done. – maxbeaudoin Jul 26 '11 at 15:53
  • I write tests for small isolated components, I don't test web forms. I would test a controller if I had to. – maxbeaudoin Jul 26 '11 at 15:55
  • If you're writing in web forms I can see the argument against testing since unless you're very strict with yourself it can very hard to do. You seem to be saying you just want to bang out code and move on. If so then fine - but you can't turn it into a virtue. What you are doing is generating lower quality code - but sometimes you have to do that. Provided you charge for bug fixes it can make good business sense :) – James Gaunt Jul 26 '11 at 15:56
  • Awh, I don't want to sound like I bang out code... I want to find the right pattern and deliver quality code without unnecessary overhead. – maxbeaudoin Jul 26 '11 at 15:58
  • If you're using DI you should be injecting your DbContext. Calling the Container Directly will add a lot of difficulty to testing due to the coupling, not to mention making the code more complicated. – Brook Jul 26 '11 at 15:59
  • I recently gave up on ORMs (after several projects with NHibernate and Entity Framework). I just use a thin code generated layer that does basic CRUD. The simpler you make the DAL the easier it is to test. But can't get behind not testing - if you consider testing an overhead then you're not doing it right - or you're an amazing programmer who never creates bugs. – James Gaunt Jul 26 '11 at 16:03

2 Answers2

3

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.

Steve
  • 1,596
  • 1
  • 10
  • 21
  • This might help me sleep better, thanks. I'm about to start a new web site and I'm not yet convinced that I'm on the right track. – maxbeaudoin Jul 26 '11 at 17:14
  • the good thing with this way of working anyway is that you are querying the object at the same location, so if you are to "upgrade" you DAL to repository adding some cache system for instance, it is very simple. – Arthis Jul 27 '11 at 07:13
2

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

Community
  • 1
  • 1
Arthis
  • 2,283
  • 21
  • 32
  • Thanks, I think what I need is a DAO. However, I like the specifications and might just implement it.. I'm also working on adding an interface.. – maxbeaudoin Jul 26 '11 at 17:13