Comments on: Query Objects vs Methods on a Repository http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/ Enterprise Development Expert & SOA Specialist Sun, 14 Mar 2010 06:27:00 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Part 8: DAOs, Repositories, or Query Objects - NHibernate blog - NHibernate Forge http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-36673 Part 8: DAOs, Repositories, or Query Objects - NHibernate blog - NHibernate Forge Mon, 07 Sep 2009 18:50:15 +0000 http://udidahan.weblogs.us/archives/436#comment-36673 [...] In fact, these days we’re not even clear which is which. There are differing opinions all over the [...] [...] In fact, these days we’re not even clear which is which. There are differing opinions all over the [...]

]]> By: Hendry Luk http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-36077 Hendry Luk Sun, 22 Mar 2009 12:09:06 +0000 http://udidahan.weblogs.us/archives/436#comment-36077 I think the problem with first option is from unit-test perspective. Yes each query is easy to be unit-tested easily (just like it's easy to test specific repository's method in option 2), but it's extremely difficult to mock the query out (e.g. to test the layer above it, like UI controller or app-service). In the option 2, we can just mock the whole repository and assert the interaction with their query methods. But in option 1, there's no easy way to mock the query (without TypeMock). I'm quite a fan of the first option myself (particularly I don't want my repository method to depend on filtering criteria on UI, because UI changes often and this ideally should not affect data layer). But I'm wondering how you can write unit-test for UI controller that uses querying approach 1? Yes, I could test the UI agains fake database, but that's essentially testing the query (that has been tested in isolation), and I only want to care about it interacts with correct query. And another question is, in the case of query that reflects search-screen, which layer do you prefer the query to live in? Yes ideally it should be in data layer, but that feels wrong to create a class in data-layer for something very specific to particular UI design. What's your opinion about query objects that live in UI or application layer? Thanks I think the problem with first option is from unit-test perspective. Yes each query is easy to be unit-tested easily (just like it’s easy to test specific repository’s method in option 2), but it’s extremely difficult to mock the query out (e.g. to test the layer above it, like UI controller or app-service).
In the option 2, we can just mock the whole repository and assert the interaction with their query methods.
But in option 1, there’s no easy way to mock the query (without TypeMock).
I’m quite a fan of the first option myself (particularly I don’t want my repository method to depend on filtering criteria on UI, because UI changes often and this ideally should not affect data layer).
But I’m wondering how you can write unit-test for UI controller that uses querying approach 1? Yes, I could test the UI agains fake database, but that’s essentially testing the query (that has been tested in isolation), and I only want to care about it interacts with correct query.
And another question is, in the case of query that reflects search-screen, which layer do you prefer the query to live in? Yes ideally it should be in data layer, but that feels wrong to create a class in data-layer for something very specific to particular UI design. What’s your opinion about query objects that live in UI or application layer?

Thanks

]]> By: Score keeping hockey and DDD « Justin Rudd’s Drivel http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-27800 Score keeping hockey and DDD « Justin Rudd’s Drivel Mon, 21 Jul 2008 01:17:39 +0000 http://udidahan.weblogs.us/archives/436#comment-27800 [...] older posts on the subjects. [...] older posts on the subjects.

]]> By: » Performant and Explicit Domain Models http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-2153 » Performant and Explicit Domain Models Fri, 08 Jun 2007 23:14:05 +0000 http://udidahan.weblogs.us/archives/436#comment-2153 [...] Query Objects vs Methods on a Repository - discussing the scalability (in terms of number of developers and queries) of Query Objects. 43ce [...] [...] Query Objects vs Methods on a Repository – discussing the scalability (in terms of number of developers and queries) of Query Objects. 43ce [...]

]]>