Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Rule #1: Keep your domain model simple and straightforward. </p> <p>First, don't prematurely optimize something because you think it may be inefficient. Build your domain so that the objects and syntax flow correctly. Keep the interfaces clean: $user->addMessage($message) is clean, precise and unambiguous. Underneath the hood you can utilize any number of patterns/techniques to ensure that integrity is maintained (caching, lookups, etc). You can utilize Services to orchestrate (complex) object dependencies, probably overkill for this but here is a basic sample/idea.</p> <pre><code>class User { public function addMessage(Message $message) { // One solution, loop through all messages first, throw error if already exists $this-&gt;messages[] $message; } public function getMessage() { return $this-&gt;messages; } } class MessageService { public function addUserMessage(User $user, Message $message) { // Ensure unique message for user // One solution is loop through $user-&gt;getMessages() here and make sure unique // This is more or less the only path to adding a message, so ensure its integrity here before proceeding // There could also be ACL checks placed here as well // You could also create functions that provide checks to determine whether certain criteria are met/unmet before proceeding if ($this-&gt;doesUserHaveMessage($user,$message)) { throw Exception... } $user-&gt;addMessage($message); } // Note, this may not be the correct place for this function to "live" public function doesUserHaveMessage(User $user, Message $message) { // Do a database lookup here return ($user-&gt;hasMessage($message) ? true } } class MessageRepository { public function find(/* criteria */) { // Use caching here return $message; } } class MessageFactory { public function createMessage($data) { // $message = new Message(); // setters return $message; } } // Application code $user = $userRepository-&gt;find(/* lookup criteria */); $message = $messageFactory-&gt;create(/* data */); // Could wrap in try/catch $messageService-&gt;sendUserMessage($user,$message); </code></pre> <p>Been working with Doctrine2 as well. Your domain entity objects are just that objects...they should not have any idea of where they came from, the domain model just manages them and passes them around to the various functions that manage and manipulate them.</p> <p>Looking back over, I'm not sure that I completely answered your question. However, I don't think that the entities themselves should have any access to the mappers. Create Services/Repositories/Whatever to operate on the objects and utilize the appropriate techniques in those functions...</p> <p>Don't overengineer it from the onset either. Keep your domain focused on its goal and refactor when performance is actually an issue.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing the Data Mapper Pattern, Should the Entities (Domain Objects) know about the Mapper?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USjsuggs
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUsing the Data Mapper Pattern, Should the Entities (Domain Objects) know about the Mapper?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COYeah, I'm with you on design patterns, and looping through all the messages is the simple solution - but that means (assuming a large quantity of messages) you're loading all the records from storage when a simple query would give the same result.
      singulars
      1. PO
      1. USTim Lytle
    2. COYeah, which is why I mentioned possibly using the doesUserHaveMessage function (or something similar). That could be where the query is done. It still keeps your entities clean and focused, but allows you to keep your domain consistent. In addition, you can start with a simple/trivial implementation (loop through array), but then refactor later when performance required it...so long as your interface stays the same no other code has to change.
      singulars
      1. PO
      1. USjsuggs
 

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