Databases
StackOverflow2013
Postsdbo
PODDD: entity's collection and repositories
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PODDD: entity's collection and repositories
    primarykey
    data
    text
    <p>Suppose I have </p> <pre><code>public class Product: Entity { public IList&lt;Item&gt; Items { get; set; } } </code></pre> <p>Suppose I want to find an item with max something... I can add the method <code>Product.GetMaxItemSmth()</code> and do it with Linq (<code>from i in Items select i.smth).Max()</code>) or with a manual loop or whatever. Now, the problem is that this will load the full collection into memory.</p> <p>The correct solution will be to do a specific DB query, but domain entities do not have access to repositories, right? So either I do</p> <pre><code>productRepository.GetMaxItemSmth(product) </code></pre> <p>(which is ugly, no?), or even if entities have access to repositories, I use <code>IProductRepository</code> from entity </p> <pre><code>product.GetMaxItemSmth() { return Service.GetRepository&lt;IProductRepository&gt;().GetMaxItemSmth(); } </code></pre> <p>which is also ugly and is a duplication of code. I can even go fancy and do an extension</p> <pre><code>public static IList&lt;Item&gt; GetMaxItemSmth(this Product product) { return Service.GetRepository&lt;IProductRepository&gt;().GetMaxItemSmth(); } </code></pre> <p>which is better only because it doesn't really clutter the entity with repository... but still does method duplication.</p> <p>Now, this is the problem of whether to use <code>product.GetMaxItemSmth()</code> or <code>productRepository.GetMaxItemSmth(product)</code>... again. Did I miss something in DDD? What is the correct way here? Just use <code>productRepository.GetMaxItemSmth(product)</code>? Is this what everyone uses and are happy with?</p> <p>I just don't feel it is right... if I can't access a product's <code>Items</code> from the product itself, why do I need this collection in <code>Product</code> at all??? And then, can <code>Product</code> do anything useful if it can't use specific queries and access its collections without performance hits?</p> <p>Of course, I can use a less efficient way and never mind, and when it's slow I'll inject repository calls into entities as an optimization... but even this doesn't sound right, does it?</p> <p>One thing to mention, maybe it's not quite DDD... but I need IList in Product in order to get my DB schema generated with Fluent NHibernate. Feel free to answer in pure DDD context, though.</p> <p>UPDATE: a very interesting option is described here: <a href="http://devlicio.us/blogs/billy_mccafferty/archive/2007/12/03/custom-collections-with-nhibernate-part-i-the-basics.aspx" rel="noreferrer">http://devlicio.us/blogs/billy_mccafferty/archive/2007/12/03/custom-collections-with-nhibernate-part-i-the-basics.aspx</a>, not only to deal with DB-related collection queries, but also can help with collection access control.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USqueen3
    1. USqueen3
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PODDD: entity's collection and repositories
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PODDD: entity's collection and repositories
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PODDD: entity's collection and repositories
      1. USChristian Specht
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload