<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Query Objects vs Methods on a Repository</title>
	<atom:link href="http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/</link>
	<description>Enterprise Development Expert &#38; SOA Specialist</description>
	<lastBuildDate>Sat, 11 Feb 2012 15:16:10 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: udidahan</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-37154</link>
		<dc:creator>udidahan</dc:creator>
		<pubDate>Wed, 07 Apr 2010 10:54:04 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-37154</guid>
		<description>Kevin,

Have you seen my more recent CQRS posts where I discuss simpler query options?</description>
		<content:encoded><![CDATA[<p>Kevin,</p>
<p>Have you seen my more recent CQRS posts where I discuss simpler query options?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-37150</link>
		<dc:creator>Kevin</dc:creator>
		<pubDate>Fri, 02 Apr 2010 21:52:14 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-37150</guid>
		<description>I did something similar to your &quot;Option 1&quot;:

    public class SubjectDAO : AbstractDAO, ISubjectDAO
    {
        public SubjectDAO(IRepository queries) : base(queries) { }

        public Subject[] GetSubjectsBy(Status status)
        {
            ISubject_SelectByStatus selectSubjectsByStatus = Queries.Find();

            return selectSubjectsByStatus.Execute(status == Status.Active ? true : false);
        }
    }


The SubjectDAO (in order to retrieve subjects by status) executes a ISubject_SelectByStatus (which in this particular example is a wrapper to a stored procedure) that receives the enumeration State by parameter, and behind the scenes opens a connection, gets an active transaction (or starts a new one), creates the paremeter(s) with the parameter received from the DAO and executes the query, converting the IDataReader to a Model &quot;Subject&quot; entity with a Converter class injected with IoC to the ISubject_SelectByStatus.

The nice thing about this example is that the query wrapper (the ISubject_SelectByStatus) is autogenerated with a home-made code generator, that &quot;reads&quot; the stored procedures and generate typed interfaces to be accessed from the DAOs.</description>
		<content:encoded><![CDATA[<p>I did something similar to your &#8220;Option 1&#8243;:</p>
<p>    public class SubjectDAO : AbstractDAO, ISubjectDAO<br />
    {<br />
        public SubjectDAO(IRepository queries) : base(queries) { }</p>
<p>        public Subject[] GetSubjectsBy(Status status)<br />
        {<br />
            ISubject_SelectByStatus selectSubjectsByStatus = Queries.Find();</p>
<p>            return selectSubjectsByStatus.Execute(status == Status.Active ? true : false);<br />
        }<br />
    }</p>
<p>The SubjectDAO (in order to retrieve subjects by status) executes a ISubject_SelectByStatus (which in this particular example is a wrapper to a stored procedure) that receives the enumeration State by parameter, and behind the scenes opens a connection, gets an active transaction (or starts a new one), creates the paremeter(s) with the parameter received from the DAO and executes the query, converting the IDataReader to a Model &#8220;Subject&#8221; entity with a Converter class injected with IoC to the ISubject_SelectByStatus.</p>
<p>The nice thing about this example is that the query wrapper (the ISubject_SelectByStatus) is autogenerated with a home-made code generator, that &#8220;reads&#8221; the stored procedures and generate typed interfaces to be accessed from the DAOs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Part 8: DAOs, Repositories, or Query Objects - NHibernate blog - NHibernate Forge</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-36673</link>
		<dc:creator>Part 8: DAOs, Repositories, or Query Objects - NHibernate blog - NHibernate Forge</dc:creator>
		<pubDate>Mon, 07 Sep 2009 18:50:15 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-36673</guid>
		<description>[...] In fact, these days we’re not even clear which is which. There are differing opinions all over the [...]</description>
		<content:encoded><![CDATA[<p>[...] In fact, these days we’re not even clear which is which. There are differing opinions all over the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hendry Luk</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-36077</link>
		<dc:creator>Hendry Luk</dc:creator>
		<pubDate>Sun, 22 Mar 2009 12:09:06 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-36077</guid>
		<description>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&#039;s easy to test specific repository&#039;s method in option 2), but it&#039;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&#039;s no easy way to mock the query (without TypeMock). 
I&#039;m quite a fan of the first option myself (particularly I don&#039;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&#039;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&#039;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&#039;s your opinion about query objects that live in UI or application layer?

Thanks</description>
		<content:encoded><![CDATA[<p>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&#8217;s easy to test specific repository&#8217;s method in option 2), but it&#8217;s extremely difficult to mock the query out (e.g. to test the layer above it, like UI controller or app-service).<br />
In the option 2, we can just mock the whole repository and assert the interaction with their query methods.<br />
But in option 1, there&#8217;s no easy way to mock the query (without TypeMock).<br />
I&#8217;m quite a fan of the first option myself (particularly I don&#8217;t want my repository method to depend on filtering criteria on UI, because UI changes often and this ideally should not affect data layer).<br />
But I&#8217;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&#8217;s essentially testing the query (that has been tested in isolation), and I only want to care about it interacts with correct query.<br />
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&#8217;s your opinion about query objects that live in UI or application layer?</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Score keeping hockey and DDD &#171; Justin Rudd&#8217;s Drivel</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-27800</link>
		<dc:creator>Score keeping hockey and DDD &#171; Justin Rudd&#8217;s Drivel</dc:creator>
		<pubDate>Mon, 21 Jul 2008 01:17:39 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-27800</guid>
		<description>[...] older posts on the subjects.</description>
		<content:encoded><![CDATA[<p>[...] older posts on the subjects.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: &#187; Performant and Explicit Domain Models</title>
		<link>http://www.udidahan.com/2007/03/28/query-objects-vs-methods-on-a-repository/comment-page-1/#comment-2153</link>
		<dc:creator>&#187; Performant and Explicit Domain Models</dc:creator>
		<pubDate>Fri, 08 Jun 2007 23:14:05 +0000</pubDate>
		<guid isPermaLink="false">http://udidahan.weblogs.us/archives/436#comment-2153</guid>
		<description>[...] Query Objects vs Methods on a Repository - discussing the scalability (in terms of number of developers and queries) of Query Objects.   43ce [...]</description>
		<content:encoded><![CDATA[<p>[...] Query Objects vs Methods on a Repository &#8211; discussing the scalability (in terms of number of developers and queries) of Query Objects.   43ce [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

