Я разработчик PHP, я читал о технологиях Java EE, и я хочу реализовать такие технологии (n-level, EJB, JPA …) с PHP и все, что происходит с (MySQL, Apache …).
Не.
PHP не является Java. Написание PHP-кода, как и для написания кода Java, является глупым и контрпродуктивным. Очень вероятно, что будущие разработчики кода захотят причинить вам вред.
Необходимо сохранить объект? Используйте ORM .
Нужна многоуровневая архитектура? Если вы разработали свой код с надлежащим разделением проблем, вы уже получили 9 / 10th пути туда.
EJBs? Каждый раз, когда я читаю статью в Википедии, они описываются по-разному. Многоразовые компоненты? Со стандартным интерфейсом для чего, распределенные приложения и постоянство данных? Полезно, да, но это не PHP. ORM и хорошая очередь сообщений / рабочих выполнят свою работу.
Суть: для подавляющего большинства PHP-скриптов вам не нужны никакие «корпоративные технологии». Если вы это сделаете, вы делаете что-то не так: либо вы переархивировали приложение, либо выбрали неправильную платформу.
Начните с выбора современной фреймворк PHP и создайте приложение оттуда. Если вы идете с Java, то Zend Framework будет казаться наименее иностранным. Кохана, Симфония и CodeIgniter – все это стоит. Избегайте пирога на данный момент.
Держите его простым, и вы не ошибетесь.
Ваш вопрос проницателен. Это потому, что по мере того, как ваше предприятие становится более успешным, оно должно масштабироваться для поддержки загрузки большего количества трафика. Таким образом, вам придется разделить свой PHP-код на слои, которые работают на разных уровнях (отдельные серверы или отдельные виртуальные машины, такие как Xen).
Например, я разработал систему в прошлом году, реализованную в PHP на 10 Linux-серверах OpenSUSE, на которых запущено около 25 виртуальных машин Xen (VM). Некоторые из VM были балансировщиками нагрузки, некоторые из них были уровнями первого уровня, некоторые из них были средними уровнями, а некоторые из них были back- конечные уровни, некоторые из которых содержат базы данных MySQL, и у нас было несколько выделенных серверов, которые были массивами RAID для хранения файлов пользователей. Мы создали NFS монтировки, необходимые для сохранения / чтения файлов в / из массива RAID.
Мы сгруппировали уровни в три связанные группы, поэтому у нас могли быть независимые тестовые сайты для QA, Staging (User Acceptance) и Production.
Поэтому наше программное обеспечение PHP было разделено на слабосвязанные слои следующим образом:
ПЕРЕДНИЙ УРОВЕНЬ (ВМ)
MIDDLE TIER (VM)
BACK-END TIER (VM)
Идея другого респондента, возникшего из использования Framework для корпоративного программного обеспечения, кажется мне довольно глупой. Если вы разрабатываете студенческий проект или «доказательство концепции» на одном сервере, и если вы уже знакомы с каркасом, он может использовать его для быстрого прототипирования.
Но, как вы видите из вышесказанного, когда вы пишете код качества продукции, распределенный между несколькими уровнями, вам не нужен костыль использования Framework.
Где бы вы поместили фреймворк во все места в вашем коде? На каждом уровне? Плохая идея. Рамки включают в себя много страниц, которые могут вам понадобиться, и вам может и не понадобиться. Таким образом, они замедляют работу, особенно при умножении на каждый уровень, на котором вы должны установить их.
Столь же неэффективным было бы создание «слоя», чтобы содержать структуру, которую должен был бы вызвать любой другой уровень. Преимущество программных уровней состоит в том, чтобы быть свободно связанными и независимыми от других слоев, так что, когда изменения происходят в одном слое, они не требуют изменений на другом уровне.
Кроме того, разработчикам, которые пишут код качества продукции, не нужно полагаться на «швейцарский армейский нож», который представляют Frameworks. Такие разработчики вполне способны написать целевой эффективный код и, при необходимости, повторно использовать классы в библиотеке, которую они, возможно, разработали для предыдущих проектов.