Databases
StackOverflow2013
Postsdbo
POExpected behaviour of a Repository
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POExpected behaviour of a Repository
    primarykey
    data
    text
    <p>I'm writing an ORM and am unsure of the expected behaviour of the Repository, or more precisely, the frontier between the Repository and the Unit Of Work. From my understanding, a Repository might look like this:</p> <pre><code>interface IPersonRepository { public function find(Criteria criteria); public function add(Person person); public function delete(Person person); } </code></pre> <p>According to Fowler (<em>PoEAA</em>, page 322):</p> <blockquote> <p>A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. [...] Objects can be added to and removed from the Repository, as they can from a simple collection of objects.</p> </blockquote> <p>This would imply that the following test should work (assuming that we already have a Person persisted, whose last name is Fowler):</p> <pre><code>collection = repository.find(lastnameEqualsFowlerCriteria); person = collection[0]; assertEquals(person.lastname, "Fowler"); person.lastname = "Evans"; newCollection = repository.find(lastnameEqualsFowlerCriteria); assertFalse(newCollection.contains(person)); </code></pre> <p>That means that when mapping to a database, even if no explicit save() method has been called somewhere, the Person model must have been automatically persisted by the Repository, so that the next query returned the correct collection, <strong>not</strong> containing the original Person.</p> <p>But, isn't that the role of the Unit Of Work, to decide which model to persist to the database, and when?</p> <p>In the above implementation, the Repository has to decide to persist the Person previously retrieved when receiving another find() call, so that the result is consistent with the modification. But if no other find() call were issued, the model would not have been persisted implicitly at all.</p> <p>In the context of a Unit Of Work, it is not really a problem, because we can start a transaction at the beginning, and rollback any insert to the db anyway if needed. But when used alone, can't this Repository lead to unexpected, unpredictable behaviour?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USBenjamin
    1. USBenjamin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    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