Я почти закончил свой Data Mapper, но теперь я нахожусь в точке, где это касается отношений.

Я постараюсь проиллюстрировать свои идеи здесь. Я не смог найти хорошие статьи / информацию по этой теме, поэтому, может быть, я заново изобретаю колесо (наверняка, я мог бы просто использовать большой фреймворк - но я хочу научиться этому).

Отношения 1: 1

Во-первых, давайте посмотрим на отношения 1: 1. В общем, когда у нас есть класс домена с именем «Company» и класс «Address», у нашего класса Company будет что-то вроде address_id. Допустим, в большинстве случаев мы просто отображаем список компаний, а адрес нужен только тогда, когда кто-то смотрит на детали. В этом случае мой Data Mapper (CompanyDataMapper) просто загружается лениво, что означает, что он просто извлечет этот address_id из базы данных, но не выполнит объединение для получения данных адреса.

В общем, у меня есть метод получения для каждого отношения. Так что в этом случае есть метод getAddress (Company companyObject). Он берет объект компании, ищет его свойство адреса и - если он равен NULL - выбирает соответствующий объект Address из базы данных, используя класс Mapper для этого объекта Address (AddressDataMapper), и назначает этот объект адреса свойству address указанного объект компании.

Важное замечание: разрешено ли Data Mapper использовать другой Data Mapper?

Допустим, в большинстве случаев вам нужен как объект компании, так и объект адреса, потому что вы всегда отображаете его в списке все вместе. В этом случае CompanyDataMapper не только выбирает объекты компании, но и выполняет запрос SQL с JOIN, чтобы также получить все поля объекта адреса. Наконец, он перебирает набор записей и передает новым объектам их соответствующие значения, назначая объект адреса объекту компании.

Звучит просто, пока.

Отношения 1: n

Как на счет этих? Единственное отличие от 1: 1 состоит в том, что Компания может иметь несколько объектов Address. Давайте посмотрим: когда большую часть времени мы интересуемся только Компанией, Data Mapper просто установит для свойства адреса объекта компании значение NULL. Свойство address - это массив, который может ссылаться на один, несколько или несколько адресов. Но мы пока не знаем, так как загружаемся лениво, так что это просто NULL. Но что, если нам понадобятся все адреса в большинстве случаев? Если бы мы отображали большой список со всеми компаниями вместе со всеми их адресами? В этом случае вещи начинают становиться действительно ужасными. Во-первых, мы не можем присоединиться к таблице адресов пятьдесят раз для каждого объекта адреса (я твердо верю, что это невозможно, и если это так, производительность будет ниже нуля). Таким образом, когда мы думаем об этом в будущем, в этом случае невозможно НЕ загружать лениво.

Важно: это правда? Должен ли я отправить 100 запросов, чтобы получить 100 адресных объектов, если у меня есть 10 компаний с каждыми 10 адресами?

Отношения m: n

Допустим, объект адреса содержит только страну, штат, город, дорогу и номер дома. Но один дом мог бы быть башней большого бизнеса с большим количеством компаний в них. Как одно из тех современных офисных зданий, где каждый может арендовать небольшую комнату, чтобы показать эту башню на своем веб-сайте. Итак: многие компании могут использовать один и тот же адрес.

У меня пока нет планов по решению этой проблемы.

Важно: Вероятно, это не большая проблема, чем отношения 1: n?

Если кто-то знает хороший ресурс, в котором подробно рассказывается о решении / реализации этого, я был бы рад ссылке!