PHP → Массивы моделей в MVC — вкусно и тяжело?
Парадигма MVC во многом позволяет упростить поддержку кода за счет разделения логики и создания абстракций, однако часто, следуя принципу Thick Model & Thin Controller (он же Fat Model & Skinny Controller), разработчикам приходится упираться в краеугольный камень использования любого объекта-модели, а именно — в потребление памяти. Что особенно актуально при работе с моделями, которые реализуют ORM (или ActiveRecord паттерн).
В данной статье хочу вкратце продемонстрировать стандартные подходы к решению данной проблемы.
JAVA → Микро-ORM своими руками (часть первая) из песочницы
Что подвигло меня на написание данной библиотеки и чем плохи существующие решения:
К сожалению такие монстры как Hibernate «тяжеловесны» и навязывают свой API для работы с БД. Мне же нужна была простенькая библиотечка, использовать которую можно было бы в перемешку с обычным JDBC-кодом (по сути мне нужно было некоторое подобие Dapper.NET для JDBC).
Основные принципы, используемые при написании библиотеки:
К сожалению такие монстры как Hibernate «тяжеловесны» и навязывают свой API для работы с БД. Мне же нужна была простенькая библиотечка, использовать которую можно было бы в перемешку с обычным JDBC-кодом (по сути мне нужно было некоторое подобие Dapper.NET для JDBC).
Основные принципы, используемые при написании библиотеки:
- простота и атомарность — библиотечка представляет собой 1 java-файл, для добавления в проект достаточно просто добавить файлик к своим исходникам.
- ненавязчивость — библиотечка не навязывает свой API, возможно использование «вперемешку» с обычным JDBC-кодом
- независимость — библиотечка не использует ничего кроме Java SE 5
- расширяемость — библиотечка поддерживает добавление расширений, необходимых для конкретного проекта
Node.JS → Маршрутизация запросов в Autodafé
Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089/
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.
Откуда берется пыль
Начнем со схемы, отображающей подключение клиентов к приложению:
На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)
В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.
Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.
Node.JS → Autodafé
Autodafe — node.js фреймворк для разработки веб приложений
Самые вкусные плюшки из коробки:
- архитектура: MVC + подключаемые модули
- Mysql ORM (ActiveRecord с поддержкой отношений, асинхронное подобие того, что предлагает Yii framework для PHP )
- HTTP сервер
- WebSockets ( обертка для socket.io )
- удобное перенаправление запросов и человеко понятные УРЛ
- управление пользователями
- аутентификация и авторизация, сессии
- система управления правами ролей пользователей
- почта ( обертка для emailjs )
- логирование в консоль, фс и на почту
- юнит тестирование ( обертка для vows )
- шаблонизатор ( расширенный dust )
Ложка дегтя:
- очень малая часть задокументирована
- задокументированная часть плохо задокументирована
- плохо задокументированная часть задокументирована только на русском языке
- тестами покрыт не весь фреймворк
PHP → RedBeanPHP — еще одна ORM библиотека
На хабре нашел пару упоминаний про эту ORM, да и то давно и в комментариях. Недавно обнаружил, что вышла уже вторая версия. Желающим — вот ссылка на загрузку (GitHub) и на документацию
Цель этой статьи — кратко познакомить читателей с этой ORM-библиотекой.
RedBeanPHP — еще одна ORM-библиотека. Основное ее отличие от коллег, типа Propel или Doctrine, в отсутствии необходимости ручного конфигурирования объектов. Т.е. никаких xml, yml или ini-файлов. RedBenPHP на лету создает таблицы, поля и индексы. Любой объект можно связать с другим. Из БД поддерживаются MySQL, SQLite и Postgres.
Doctrine ORM → Пользовательские репозитории в ORM Doctrine 2 из песочницы
В большинстве случаев стандартные методы, генерируемые доктриной на основе Yaml (XML или аннотаций), хватает только на получение каких то полей по какому-то простому фильтру. Для более сложного запроса приходиться пользоваться нативным QueryBuilder'ом и обращаться через dql запросы к нашей модели. Все это является следствием нагромождения больших кусков кода, которые имеют свойства дублироваться там где требуется применить идентичные запросы. А как хотелось бы обращаться с моделью просто и красиво через один единственный метод? Как? Напишем свой!
LiveStreet CMS → LiveStreet и ORM из песочницы
Выход версии 0.5 для меня было нечто большим, чем добавление страницы активности и ленты топиков из подписанных блогов. В новой версии реализованы ORM и ActiveRecord. Вместе они дают мощнейший инструментарий для разработчика, избавляя того от кучи однотипного кода, который приходилось писать каждый раз при разработке плагина. Тот-же форум, о котором будет идти речь в статье, после обновления похудел на 2177 строк кода. В этой статье я хочу углубиться в ORM и AR на примере создания плагина для LiveStreet.
Django Framework → Cacheops
Некоторое время назад я писал о системе кеширования. Помнится, я обещал продолжение, но сейчас решил, что строка кода лучше сотни комментариев, теорию оставим на потом. Поэтому сегодня у нас своего рода анонс с парой советов по использованию в одном флаконе. Встречайте, cacheops — система кеширования и автоматической инвалидации кеша для Django ORM.
Zend Framework → ORM генератор для Zend Framework на Perl
Использование объектно-реляционного проецирования (ORM) стало в настоящее время фактически негласным стандартом при разработке Web-приложений Enterprise-уровня и использовании реляционных СУБД.
В настоящее время наиболее популярным способом решения данной проблемы является использование проектора Doctrine, реализующего паттерн ActiveRecord. Несмотря на соблазн «прикрутки» готового решения, многие команды идут по пути написания собственного ORM-движка. В частности, совсем недавно об опыте разработки собственного ORM рассказывал разработчик geometria.ru Михаил Шамин в своем докладе на проходившей в мае в Санкт-Петербурге конференции ZF Conf 2011.
О преимуществах и недостатках того или иного подхода можно спорить, но этот спор выходит за рамки целей данной статьи. А в этой статье я расскажу об опыте разработки и использования простейшего генератора готовых к использованию ORM-классов, реализующих стандартный CRUD-функционал (create, read, update, delete), и готовых к использованию в приложении на базе Zend Framework.