anonymous@RULINUX.NET~# Last login: 2024-04-19 06:24:25
Регистрация Вход Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск
[#] [Добавить метку] [Редактировать]
Скрыть

Сущности Doctrine.

Итак что я предлагаю сделать сущностями:

  •  юзера

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

  •  блок

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

  •  сообщение

  •  тред

  •  подраздел.

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

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

Tux-oid(*) (2012-05-07 09:46:46)

Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120422 Firefox/12.0 SeaMonkey/2.9

[Ответить на это сообщение]
[#] [Добавить метку] [Редактировать] Ответ на: Сущности Doctrine. от Tux-oid 2012-05-07 09:46:46
avatar
Скрыть

Re:Сущности Doctrine.

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

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

SystemV(*)(2012-05-07 23:44:45)

Emacs-w3m/1.4.468 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Сущности Doctrine. от SystemV 2012-05-07 23:44:45
avatar
Скрыть

Re:Сущности Doctrine.

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


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



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

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

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





Ax-Xa-Xa(*)(2012-05-08 00:03:46)
Отредактировано Ax-Xa-Xa по причине "не указана"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.168 Safari/535.19
[#] [Добавить метку] [Редактировать] Ответ на: Re:Сущности Doctrine. от Ax-Xa-Xa 2012-05-08 00:03:46
avatar
Скрыть

Re:Сущности Doctrine.

>Бандал на новости, бэндал на галерею. Сорри чем эти бэндлы будут отличаться друг от другу?
Ну сейчас они отличаются. Всё хранится в одной таблице, но для некоторых данных поля остаются пустыми. Шаблоны разные, в коде же if ($section_id == 1) ... и т.д. Отсюда, собственно, и возникла идея сделать бандлами.

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

SystemV(*)(2012-05-08 01:52:07)

Emacs-w3m/1.4.468 w3m/0.5.3
[#] [Добавить метку] [Редактировать] Ответ на: Re:Сущности Doctrine. от Ax-Xa-Xa 2012-05-08 00:03:46
avatar
Скрыть

Re:Сущности Doctrine.

> Бандал на новости, бэндал на галерею. Сорри чем эти бэндлы будут отличаться друг от другу? По хорошому и модуль личного блога не сильно будет отличаться от модуля новостей.

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

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

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

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

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

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

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

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

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

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

anonymous(*)(2012-05-08 03:26:37)

Этот тред читают 1 пользователь:
Анонимных: 1
Зарегистрированных: 0




(c) 2010-2020 LOR-NG Developers Group
Powered by TimeMachine

Valid HTML 4.01 Transitional Правильный CSS!