моя архитектура PHP надежна?

Question

Я пытаюсь спроектировать надежную серверную архитектуру и придумал следующее:

http://www.monsterup.com/image.php?url=upload/1235488072.jpg

Клиентская сторона общается только с одним файлом сервера с именем process.php, где проверяются права пользователя; и куда направляется действие. Затем бизнес-классы обрабатывают бизнес-логику и выполняют проверку данных. Все они содержат класс DataAccessObject, который выполняет операции с БД.

Не могли бы вы указать на различные недостатки, которые может иметь такая архитектура? Что касается безопасности, гибкости, экстенсивности, ...?

Answer 1

Ваша архитектура не идеальна. Это никогда не будет идеально. Когда-либо. Быть идеальным невозможно. Это природа разработки приложений, программирования и мира в целом. Появится требование добавить функцию или изменить бизнес-логику, и вы вернетесь к этой архитектуре и скажете: «Что в мире было, я думаю, это ужасно». (Надеюсь ... иначе вы, вероятно, не узнали ничего нового!)

Проведите инвентаризацию ваших целей, если это будет:

эта архитектура идеально подходит

или вместо:

эта архитектура функционирует там, где мне это нужно, и позволяет выполнить работу

Answer 2

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

Это поможет вам отделить вашу бизнес-логику от вашего HTML , упрощая поддержку.

Это обычный способ разработки приложения.

Еще одна вещь, которую вы можете сделать, - это иметь другой класс, обрабатывающий делегирование действия . Хотя это действительно зависит от сложности вашего приложения.

Книга Объекты, шаблоны и практика PHP может дать вам реальное представление об архитектуре приложения.

Answer 3

Я вижу пару вещей.

Во-первых, я согласен с другими, что вы должны добавить какой-либо слой вида, хотя я не уверен насчет Smarty (я часто его использую, и у меня действительно есть сомнения в эти дни, но я отвлекаюсь) Дело в том, что вам нужно отделить HTML-код где-то в шаблоне, чтобы его было легко изменить. Эта точка не колеблется, если вы используете много AJAX. AJAX по-прежнему требует, чтобы вы (обычно) помещали элементы div вокруг страницы и т. Д. Поэтому ваш макет должен быть отделен от кода обработки.

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

Ваша методология "диспетчер / диспетчер" кажется разумной. Операторы switch исключают необходимость любого вида сопоставления URL -> кода, что затрудняет управление и требует масштабирования кэширования.

Это мои $ 0,02

Answer 4

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

1. Расширяемость: как правило, чем более абстрактна и слабо связана архитектура, тем она более расширяема. Именно поэтому другие рекомендовали использовать слой представления, который бы абстрагировал шаблоны уровня представления для каждой пары «класс: действие» в свой собственный файл.

2. Ремонтопригодность: это идет рука об руку с расширяемостью. Как правило, чем более расширяемой является архитектура, тем более она обслуживаема (возьмем это с точки зрения соли, потому что это не всегда так). Попробуйте добавить слой модели под слой логики модели. Это поможет вам заменить логику доступа к данным на бизнес-логику модели.

3. Безопасность. Недостатком вашей архитектуры является то, что вам действительно необходимо инвестировать в тестирование безопасности. Поскольку весь ваш код перенаправления / маршрутизации находится в process.php, этот файл несет большую ответственность, и любые изменения в нем могут привести к потенциальной лазейке в безопасности. Это не обязательно неправильно, вам просто нужно знать о рисках.

4. Масштабируемость: ваша архитектура сбалансирована и выглядит очень масштабируемой. Так как он разбит по классам: действиям, вы можете добавить кэширование на любом слое, чтобы повысить производительность. Добавление дополнительного уровня модели доступа к данным также поможет вам кэшировать на уровне, ближайшем к базе данных.

Наконец, экспериментируйте с каждой архитектурой и не бойтесь делать ошибки. Кажется, вы уже хорошо понимаете MVC. Единственный способ стать лучше в архитектуре - это внедрить и протестировать ее в «реальном мире».

Answer 5

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

class1
{
  action1.1
  action1.2
  ...
  action1.N
}

class2
{
   action2.1
   action2.2
   ...
   action2.N
}

Как злоумышленник, я первым делом посмотрел бы на состояние, в котором действие не соответствует его соответствующему классу. Я бы попытался представить class1 с action2.1 вместо action1.1.

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

Вы станете лучшим разработчиком, если будете делать ошибки, а затем учиться на них (кроме программного обеспечения для наведения ракет, у вас там будет только одна попытка).