Дао шаблон и отношения

Question

Я работаю с паттерном DAO в PHP.Я понимаю преимущества, которые вы получаете от разделения вашей модели таким образом, но я не понимаю, как вы должны строить DAO и VO, когда ваши таблицы связаны через ассоциативную сущность

Я дампример:

В моей БД у меня есть

USERS(id,username);

USERS_POSTS(id_user(FK),id_post(FK));

POSTS(id, title);

USER_COMMENTS(id_user(Fk),id_post(FK));

COMMENTS(id, text);

Я создаю UserVO , PostVO с соответствующими установщиками и получателями, а затем UserDAO и PostDAO отвечает за SQL, которые в конце возвращают VO.Выполнение операций CRUD для данных из этих таблиц действительно просто, но когда вы начинаете думать о связывании таблиц и извлекать данные из разных таблиц, вы начинаете думать, что использование DAO уже не так просто ...

Как бы вы организовали свой шаблон DAO, если вы хотите вернуть все комментарии, сделанные автором статьи?Мне не нужен SQL-запрос, который я просто привожу в качестве примера реальной ситуации ...

Я читал, что было бы неплохо иметь ассоциативные DAO и Vo для каждой ассоциативной таблицы.Из чего состоит его экшн?Всего 2 внешних ключа или из всех атрибутов из обеих таблиц?

Если логика имеет DAO и VO для ассоциативного объекта, каковы решения, если запрос проходит "через" более 3 таблиц (используя 2 ассоциативных объекта)?

Я сомневаюсь, что в шаблоне DAO будет объект с именем users_posts_comments_article:)))

Спасибо

Answer 1

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

Вот чтение, которое определенно даст вам пищу для размышлений: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Цитата из этой статьи (он имеет в виду доменные модели):

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

Answer 2

Будьте проще, с. DAO или любая другая философия или что-либо может иметь смысл только до определенного предела.

ИМХО, это пустая трата времени для такой простой вещи, как блог, если вы хотите абстрагироваться, просто перейдите к простому getitem ('class', $ condition) или получите связь ($ pathandconditions, $ itemconditions).

Такие вещи определенно покрывают все потребности, которые вы можете иметь для базового использования SQL.

getUsersWhoHaveAFrigginLongMethodNameofDoom - действительно плохая идея, определение таких неабстрагированных чрезмерно копируемых / вставленных функций идет вразрез с ремонтопригодностью и т. Д.