Comments on: Limiting your abstractions

By: Rodi de Boer

Rodi de Boer — Sun, 10 Feb 2013 15:17:00 +0000

Ok, so what’s the plan if you have several “front-ends” on the same domain intersecting; for example an MVC app that let’s users do things like management of certain things and a web service that lets other systems do things (some management and some other stuff too)?
Would you just use the Task/TaskExecuter scenario for all the intersecting functionality?
And is that Task scenario an implementation of the Command pattern?

By: Rodi de Boer

Rodi de Boer — Fri, 08 Feb 2013 18:30:00 +0000

Nice post. I think I’m starting to get this. So we don’t just do a repository, but we encapsulate and introduce the right OO pattern at the momet we find the need to really do so.
Thanks. All those posts on the internet; combining them to something I can digest and make my own is pretty hard.

By: Dariusz Gil

Dariusz Gil — Sun, 11 Nov 2012 23:21:00 +0000

In short: Repo – bunch of methods FindSomethingXXXBy, Query Object: one query use case per class. And/Or you can use extension methods

By: Favor query objects over repositories | Jimmy Bogard's Blog

Favor query objects over repositories | Jimmy Bogard's Blog — Mon, 05 Nov 2012 14:55:09 +0000

[...] I’m over Repositories, and definitely over abstracting your data layer, but where does that leave us? I don’t think creating an abstraction over your ORM provides much [...]

By: JustinBMichaels

JustinBMichaels — Mon, 29 Oct 2012 14:01:00 +0000

Jimmy, how would you approach integration testing with your ORM querying being done in your controller’s action? Do you integration test your controllers by asserting against your ViewResult.Model or do you go for an automated Ui test and verify against the html? I guess my confusion or over analyzing is happening when trying to test that my query returned what was expected.

By: Paul Tiseo

Paul Tiseo — Wed, 17 Oct 2012 20:23:00 +0000

Could you explain the difference between your Repository object and your Query object?

By: Josh

Josh — Tue, 09 Oct 2012 22:11:00 +0000

Can you please do a post expanding on your testing strategies around these ideas? You mention it briefly, and perhaps I’m misinterpreting what you mean by ‘I only stub out components I can’t control’. I read this statement as the opposite to the advice ‘don’t mock objects you don’t own.’ If you’re calling your ORM directly, there is no way to isolate your controller test, and you’re forced to integrate test it. It sounds like you advocate the approach to create a thin wrapper around the ORM which simply delegates to it to provide a seam to isolate test your controller, but then you say ‘…it’s just a matter of swapping out the underlying session with one going against an in-memory version…’. I’m unfamiliar with RavenDB, but we use Entity Framework, and running LINQ against an in-memory store (LINQ to objects) is not the same as against the database (LINQ to Entities), so swapping the ORM doesn’t create a useful test. Is it a case that you just integrate test your controller (keeping your abstractions simple) until you need to manage the complexity by introducing some abstraction for the query, at which time you change the controller test to an isolated one?

By: John Reilly

John Reilly — Wed, 03 Oct 2012 10:35:00 +0000

Hi Jimmy,

Really good article – thank you. I’ve recently been coming to similar conclusions to you and found your post after writing a blog post about my own experiences:

http://icanmakethiswork.blogspot.co.uk/2012/10/unit-testing-and-entity-framework-filth.html

I was coming from the perspective of assuming that there must be a simple way to MOQ Entity Framework and get my unit tests up and running. It looks like I was mistaken both in the expectation that this was simple and also that it was even worthwhile!

I’ve put a link in my blog post to this as I think you probably express the underlying issue rather better than I have – hope that’s okay?

By: Anonymous

Anonymous — Sun, 30 Sep 2012 22:24:00 +0000

1) This is every single query in the system?
2) Hundreds of actions? You have other problems then. How is many objects different than many methods? It’s the same problem, now I just have a god object.

By: Evgeny mz

Evgeny mz — Sun, 30 Sep 2012 18:19:00 +0000

There are still two issues:

1) Let’s assume you want to add an additional condition .Where(post => post.Language == Language). You have to search through all your actions instead of doing it on one file (repository class);
2) Someone wants to get archived posts for N-date – he would repeat your Achive-action code because he wouldn’t be able to examine hundreds of actions to find that there’s already the code that could be abstracted in a query object as you suggested.

How do we solve those?