Нужно принять архитектурное решение по проекту…?

Question

[deco]

Здравствуйте! Уважаемое хабрасообщество, нужно принять архитектурное решение по проекту, но нет достаточного опыта. Если кто-то разрабатывал архитектуру проекта, буду благодарен за ваши советы!


Есть проект:

— One page application. Написан на Javascript: Backbone.js, jQuery, Underscore.js.

— Серверная часть написана на PHP. Фреймфорк CodeIgniter используется как роутер.

— Административная часть написана на CodeIgniter с использованием Twitter Bootstrap.

— Самописное ядро (Core). Здесь сосредоточена основная логика проекта. Core делится на модули. В ядре происходят регистрация и вызов всех модулей. Каждый модуль включает в себя код, который выполняет определенные действия над объектами (логическими частями проекта).Каждый модуль разделяется на Writer и Builder. Writer записывает информацию в базу данных MySQL. Builder получает информацию об объекте из базы данных. В каждый модуль из ядра передается драйвер для работы с базой данных. Также есть logger для логирования всех действий. Таким образом, в каждый модуль можно передавать драйвер и logger для различных баз данных.


Есть вопросы:

1. Модули имеют в себе лишь набор функций для записи или взятия информации для определенного объекта (работают напрямую с MySQL), а должен был быть ORM… Через это есть дублирующие функции. Возможно модули должны работать с паттерном DataMapper? Что можно предпринять? Модули должны возвращать или сохранять объект с набором полей для того, чтобы передать этот объект JSON-ом JavaScript-у.


2. Проект запущен для нескольких стран. Один код используется для обоих проектов, но есть некоторые различия в функционале (например ZIP код нужен только в 1 стране). Разный функционал работает таким образом, что в PHP нужно задавать «IF» по идентификатору страны, что нарушает структуру кода. Как можно это решить?


3. Есть ли смысл подключить Doctrine для работы с базой данных?


Спасибо!

Answer 1

[Анатолий]

Щас вы наслушаетесь кучу архитектурных решений и еще больше запутаетесь =) Сколько людей, столько и решений!
Но исходя из своего опыта могу посоветовать сделать пару вещей:
1. не выдумывайте ничего лишнего и не усложняйте код
2. если проект долгосрочный, всеравно будете рефакторить, поэтому делайте слабое связывание, потом проще будет кусками небольшими править
3. если не много времени, используйте те инструменты которые лучше знаете, даже если есть в 100 раз круче и весь мир их советует =)
Не бывает четких и глобальных архитектурных решений.

Comments

[VoidVolker]

Полностью согласен. Вполне нормальная архитектура. «Работает? Не трогай — а то сломаешь.» (с)
А для разделения по странам можно сделать просто два немного различающихся скрипта и для каждой страны вызывать свой.

Answer 2

[mobilz]

1. Проекты нагруженные? Тогда зачем ORM? Жрут память, жрут время, менее гибкие. Народ наоборот старается на HandlerSocket переходить при больших нагрузках. Выгрузка в json, проблем не вижу. json_encode вполне справляется.
2. В гите отдельными ветками. Есть, например, master ветка, есть galulu, для страны галулу. Прийдётся мерджить, но зато без лишнего кода. Можно делать это автоматом.
3. Опять же, смотря чего вы хотите добиться в итоге. Безопасности за счёт медленной работы? Безопасности можно добиться другими путями

Answer 3

[Александр]

1. Сложно сказать что лучше. Но можно попробовать сравнить. У нас onPHP со своим ORM. ORM удобен тем, что из сущностей можно автоматически генерировать формы с правилами полей. В результате импорт данных из фронт-енда сводится к импорту в форму, валидацию (можно еще навешать кастомные правила-проверки), заполнение ORM-объекта формой и метода-сохранения. Экспорт объекта в общем-то и так очевиден до безобразия.
Насколько такой механизм проще или сложнее — думайте сами. Но как я понимаю использование подобной технологии вынудит капитально переписывать ядро.

2. Никакие паттерны не подходят? Например Strategy.

3. См. п. 1

Я может ещё не совсем понял, но зачем логгировать именно все действия, особенно если это на уровне БД?

Answer 4

[Noquox]

1. Вопреки распространённому мнению, не ORM "замедляет" работу с базой данных, а её неумелое использование. Здесь доклад на эту тему в отношении Doctrine, а здесь слайды с доклада.
2. Согласен с @kryoz насчёт паттерна Strategy.
3. Нужно взвесить все "за" и "против", принимая во внимание аргументы из пункта первого.