Lazy Loading and Cascade Remove in Extbase
The property offers, we proceed to the equivalent property contacts. The definition of the property offers includes in the comment two special annotations: @TYPO3\CMS\Extbase\Annotation\ORM\Lazy and @TYPO3\CMS\Extbase\Annotation\ORM\Cascade remove.
/** * @var \TYPO3\CMS\Extbase\Persistence\ObjectStorage<\MyVendor\SjrOffers\Domain\Model\Offer> The offers the organization has to offer * @TYPO3\CMS\Extbase\Annotation\ORM\Lazy * @TYPO3\CMS\Extbase\Annotation\ORM\Cascade("remove") */ protected $offers;
By default Extbase invites all child objects with the parent object (so for example all offers of an organization). This behavior is called Eager-Loading. The annotation @TYPO3\CMS\Extbase\Annotation\ORM\Lazy causes Extbase to load the objects and build only when they are actually needed (lazy loading). This can be an appropriate data structure, e.g. many organizations, each with very many offers, that lead to a significant increase in speed.
Beware, however, against all the properties provided by child objects with @TYPO3\CMS\Extbase\Annotation\ORM\Lazy, because this can lead to frequent loading of child objects. The ensuing, small-scaled database accesses reduces the performance and cause then the exact opposite of what you wanted to achieve with the lazy-loading.
The annotation @TYPO3\CMS\Extbase\Annotation\ORM\Cascade("remove") causes if the organization is deleted, the offers will be also deleted immediately. Extbase leaves usually persist unchanged all child objects.
Besides these two there are a few more annotations available, which will be used in other contexts (e.g. in the controller). The complete list of all by Extbase supported annotations, see the index.
So far, the impression may arise that domain models consist only of setters and getters. The domain objects, however, contain the main part of the business logic. In the following section, we add to our class \MyVendor\SjrOffers\Domain\Model\Organization a small part of this business logic.