rulinux.net - Форум - Web-development - Сущности Doctrine. http://rulinux.net/ rulinux.net - Форум - Web-development - Сущности Doctrine. http://rulinux.net/ http://rulinux.net/rss_icon.png Re:Сущности Doctrine. https://rulinux.net/message.php?newsid=36984&page=1#138984 https://rulinux.net/message.php?newsid=36984&page=1#138984 Mon, 07 May 2012 23:26:37 +0400 > Бандал на новости, бэндал на галерею. Сорри чем эти бэндлы будут отличаться друг от другу? По хорошому и модуль личного блога не сильно будет отличаться от модуля новостей.

> Поясню на примере: Есть простой модуль авторизации и его класс прописан в конфигах DI. Через некоторое время сделали более навороченный модуль с OpenID и просто заменили старый класс на новый в конфигах DI. И все мы начали иметь OpеnID. Вот это модульность.

Именно что, есть нечто общее между всеми вхождениями. Например у них есть заголовок и как-то форматированный текст. Есть элементы галереи, новости, каменты, бог знает что ещё.

Что движку надо знать об этом? Что данный тип объекта существует, может сообщить как отобразить его в меню, знает что экземпляр объекта может отрисовать себя в формате ХТМЛ, данный тип может вывести форму для ввода нового экземпляра и редактирования существующего и т.п. Т.е. интерфейс у этих объектов идентичен.

Тут напрашивается некий базовый класс, который реализует этот интерфейс.

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

Естественный подход к решению вопроса: определить [абстрактный] базовый класс, который уже содержит методы, реализующие некие общие места и расширять этот класс для конкретных типов данных. Вместо того, чтобы каждый раз писать базовый функционал заново.

И при рефакторинге будет проще поменять определение базового класса, а не лазать по всем реализациям вправляя там что-то.

И это не вся проблема. Один и тот же базовый класс, например сторадж картинок, может иметь несколько реализаций: сторадж для скриншотов, сторадж для новостей, сторадж для бложиков пользователей. Логика и политики создания, хранения и доступа к картинкам в этих стораджах могут существенно различаться. Следовательно нам может потребоваться несколько реализаций одного и того же класса хранилища, с разными свойствами.

Всё это отлично легло бы на нормальную объектную модель без переписывания. При любом изменении общего функционала было бы достаточно изменить базовый класс.

Про DI я так и остаюсь в непонятках - зачем инжектить классам свойства, про которые они ни сном ни духом? Или я чего-то недопонимаю?

]]> Re:Сущности Doctrine. https://rulinux.net/message.php?newsid=36984&page=1#138981 https://rulinux.net/message.php?newsid=36984&page=1#138981 Mon, 07 May 2012 21:52:07 +0400 >Бандал на новости, бэндал на галерею. Сорри чем эти бэндлы будут отличаться друг от другу?
Ну сейчас они отличаются. Всё хранится в одной таблице, но для некоторых данных поля остаются пустыми. Шаблоны разные, в коде же if ($section_id == 1) ... и т.д. Отсюда, собственно, и возникла идея сделать бандлами.

Хотя, наверное, в чём-то ты прав.

]]> Re:Сущности Doctrine. https://rulinux.net/message.php?newsid=36984&page=1#138979 https://rulinux.net/message.php?newsid=36984&page=1#138979 Mon, 07 May 2012 20:03:46 +0400 > Логично, что контроллер главной страницы должен быть в главном модуле (бандле). Но тогда придётся в него вписывать уже "подключаемые" бандлы.


Элементарно Ватсон, он должен уметь читать конфиг и подключать бандлы по заранее определенному интерфейсы, если инфы с конфига будет не достаточно.



И вообще это лично моё мнение, на кажется вас слишком захватила идея бэндлов как основы модульности, но под модульность вы понимаете не расширение функциональности сайта, а добавление нового урла в меню. Бандал на новости, бэндал на галерею. Сорри чем эти бэндлы будут отличаться друг от другу? По хорошому и модуль личного блога не сильно будет отличаться от модуля новостей. И там и там пост и его обсуждение.

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

Поясню на примере: Есть простой модуль авторизации и его класс прописан в конфигах DI. Через некоторое время сделали более навороченный модуль с OpenID и просто заменили старый класс на новый в конфигах DI. И все мы начали иметь OpеnID. Вот это модульность.





]]> Re:Сущности Doctrine. https://rulinux.net/message.php?newsid=36984&page=1#138978 https://rulinux.net/message.php?newsid=36984&page=1#138978 Mon, 07 May 2012 19:44:45 +0400 Идея вроде правильная, имхо, но вот я пока не сообразил, как связывать между собой бандлы, кроме как напрямую в коде. Причем указывать главный бандл в "дополнительных" выглядит логично, а вот наоборот - странно. Как минимум, нарушается модульность.

Например, есть у нас главная страница сайта. Сейчас на ней выводятся новости и куча всякой дополнительной инфы. Логично, что контроллер главной страницы должен быть в главном модуле (бандле). Но тогда придётся в него вписывать уже "подключаемые" бандлы. С сервисами тоже не до конца понятно, можно ли на них что-то сделать, чтобы это обойти.

]]> Сущности Doctrine. https://rulinux.net/message.php?newsid=36984&page=1#138870 https://rulinux.net/message.php?newsid=36984&page=1#138870 Mon, 07 May 2012 05:46:46 +0400 Итак что я предлагаю сделать сущностями:

  •  юзера

  •  группу юзеров

  •  блок

  •  класс разметки

  •  сообщение

  •  тред

  •  подраздел.

Разделы можно делать отдельно bundle-ами(За базовую часть берется форум, новости, галерея и статьи - вынести в отдельные bundle-ы. такой подход позволит в дальнейшем, создав bundle впилить допустим личные блоги. Как я понял мое мнение поддержал SystemV).

Если я что не так понял - поправьте. Если что забыл - дополните список.

]]>