Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>One thing that i did wrong when played around with repository pattern - just like you, i thought that table relates to repository 1:1. When we apply some rules from Domain Driven Design - grouping repositories problem often disappears.</p> <p>Repository should be per <a href="http://thinkddd.com/glossary/aggregate-root/" rel="noreferrer">Aggregate root</a> and not table. It means - if entity shouldn't live alone (i.e. - if you have a <code>Registrant</code> that participates in particular <code>Registration</code>) - it's just an entity, it doesn't need a repository, it should be updated/created/retrieved through repository of aggregate root it belongs.</p> <p>Of course - in many cases, this technique of reducing count of repositories (actually - it's more a technique to structure your domain model) can't be applied because every entity is supposed to be an aggregate root (that highly depends on your domain, I can provide blind guesses only). In your example - <code>License</code> seems to be an aggregate root because you need to be able to check them with no context of <code>Registration</code> entity.</p> <p>But that does not restrict us to cascade repositories (<code>Registration</code> repository is allowed to reference <code>License</code> repository if needed). That does not restrict us to reference <code>License</code> repository (preferable - through IoC) directly from <code>Registration</code> object. </p> <p>Just try not to drive your design through complications provided by technologies or misunderstanding something. Grouping repositories in <code>ServiceX</code> just because you don't want to construct 2 repositories ain't good idea. </p> <p>Much better would be to give it a proper name - <code>RegistrationService</code> i.e. </p> <p>But services should be avoided in general - they often are cause that leads to <a href="http://en.wikipedia.org/wiki/Anemic_Domain_Model" rel="noreferrer">anemic domain model</a>.</p> <p><strong>EDIT:</strong><br> Do start to use IoC. It truly eases the pain of injecting dependencies.<br> Instead of writing: </p> <pre><code>var registrationService = new RegistrationService(new RegistrationRepository(), new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds()); </code></pre> <p>you will be able to write: </p> <pre><code>var registrationService = IoC.Resolve&lt;IRegistrationService&gt;(); </code></pre> <p>P.s. Would be better to use so called <a href="http://www.codeplex.com/CommonServiceLocator" rel="noreferrer">common service locator</a> but that's just an example.</p>
 

Querying!

 
Guidance

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