Многоуровневость в PHP... правильно?

Question

У меня конкретный вопрос, на который можно было бы дать общий ответ...При создании многоуровневых приложений на PHP все ли нужно делать на уровне бизнес-логики или может работать любой уровень...Пример. Допустим, я создаю приложение, которое отображает информацию о пользователе (из базы данных) на уровне представления.Должен ли я использовать бизнес-уровень, чтобы просто передать данные на уровень представления, или просто получить информацию из базы данных непосредственно на уровне представления.Должен ли уровень представления использоваться ТОЛЬКО для представления данных, уровень доступа ТОЛЬКО для получения данных, и вся работа должна выполняться на бизнес-уровне?

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

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

Спасибо

Answer 1

Веб-приложения и N-уровень интересны главным образом потому, что понятие N-уровня расширилось с широким распространением JSON и AJAX или Flash и XMLRPC.Этот диаграмма в Webopedia отображает шахматную синюю линию, которая хорошо это отражает.Обобщить:ваша бизнес-логика, средства доступа и логика представления могут существовать не только на сервере, но в некоторых случаях прямо в браузере.Однако целью N-уровня является отделимость.Если вам нужно изменить свой пользовательский интерфейс или базу данных или добавить другие пользовательские интерфейсы, вы не должны влиять на свою бизнес-логику.И именно это будет определять ваш API — в ожидании того дня, когда ваш HTML и CSS будут отброшены для Flex, а MySQL будет заменен на Oracle.

Это определяется требованиями, и в некоторых веб-приложениях, которые я использовал, варианты N-уровня используются одновременно.Возьмем, к примеру, LyrisHQ (ASP для электронной почты).У них есть клиентское веб-приложение.Недавно они начали продвигать свое приложение на основе Flash.Очевидно, что при этом большой объем данных передается прямо в браузер, и, вероятно, часть бизнес-логики дублируется в пользовательском интерфейсе Flash.Однако они должны поддерживать оба приложения, поскольку любое из них необходимо для разных (и пересекающихся) требований.

Большинство распространенных PHP-приложений не рассматривают отправку большого количества неформатированных данных в браузер.Но если бы это было так, это очень быстро проинформировало бы вас о том, как вы хотите разрабатывать свои API.Весьма вероятно, что вам понадобятся контроллеры, которые могут использовать XMLRPC, REST или SOAP... в дополнение к аналогичному классу внутреннего контроллера, который используется в ваших шаблонах представления PHP.Строго говоря, для простой веб-страницы входа в систему у вас будет шаблон PHP для формы входа, который взаимодействует с классом LoginController.Интерфейс XML также будет использовать тот же класс LoginController.Точно так же, как вы могли бы предположить, что были бы сумасшедшими, записывая SQL в запрос Ajax... вы бы строго избегали написания запросов в шаблонах презентаций.

Бизнес-уровни могут быть более или менее строгими, поскольку часто никогда не возникает необходимости менять бренд серверной части базы данных.При строгом N-уровневом подходе ваши бизнес-объекты будут взаимодействовать с вашей базой данных так же, как если бы вы могли переключиться с MySQL на MS SQL без переписывания бизнес-уровня.Иногда это делается путем моделирования объектов для каждой таблицы (Table Gateway), каждой строки (активной записи), каждого соединения или каждой транзакции.Здесь могут пригодиться что-то вроде PDO или PHP-ADO, но недостаточно для полной изоляции.Уровни ORM/Persistence в Java, таких как Hibernate, лучше демонстрируют этот вид изоляции, часто за счет предоставления языка объектных запросов (OQL).

Лично я в настоящее время занимаюсь переходом от PHP-приложения на базе MySQL к приложению MS-SQL.Приложение когда-либо использовало только прямые запросы SQL.Представьте себе, что вы выбираете, как взять серию запросов в классе и либо абстрагировать их, либо создать подклассы, и, надеюсь, не меняя бизнес-логику.Как минимум, вы захотите сделать все ваши вызовы SQL косвенными.(ТАК.пост на PHP ORM.)

И наконец, к вашему вопросу об ООП:используйте его так, как вам необходимо, чтобы выполнить свои требования.Мой личный метод — начать с логики прямо в шаблоне презентации PHP на несколько минут, чтобы сдвинуть дело с мертвой точки, довольно скоро я реорганизую это в класс и шаблон.Если у меня есть общие идеи, я разбиваю подпрограммы на общие классы, стремясь сохранить принцип DNRY.(А ТАК.напишите об этом здесь. ООП не является фундаментальным требованием для N-уровневого проектирования.Однако DNRY очень важен для обеспечения удобства сопровождения вашего кода.Часто сроки и сдвиг объема работ разрушают API.Рефакторируйте его, пока не получите то, что вам нужно для продолжения работы.Могу поспорить, что ООП поможет вам в этом.

Answer 2

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

Также:Это действительно зависит от проекта.На мой взгляд, не всегда имеет смысл использовать ООП для всего (вероятно, не все с этим согласятся), особенно в языках сценариев, таких как PHP, часто проще просто использовать валидаторы как функции...

Answer 3

Я определенно советую вам не использовать вызовы базы данных на уровне представления, иначе это противоречит их цели.

Существуют разные подходы к многоуровневая архитектура и у них разные рекомендации.

Zend Framework, с которым я работал, обычно представляет собой вариант Fat model/Thin Controller.

Если найти эту статью Примечания по выбору PHP-фреймворка чтобы хорошо уметь сравнивать (в данном случае) CakePHP с Zend Framework.

Самая большая разница, на мой взгляд, заключается в подходе, основанном на соглашениях над конфигурацией, принятом CakePHP, который сильно отличается от фокуса на конфигурации в Zend Framework.

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

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

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

Разница между «обычной» трехуровневой аркой и шаблоном MVC заключается в том, что представление имеет доступ как к контроллеру, так и к уровню модели, тогда как уровень представления имеет доступ только к логическому слою трехуровневой арки.

Answer 4

Я согласен с тем, что сказал Франц, особенно в отношении предпочтения более крупных моделей более крупным контроллерам.вы также можете использовать эмпирическое правило, чтобы определить, куда должен идти код:если это имеет какое-либо отношение к структуре/потоку пользовательского интерфейса, поместите его в контроллер;если это чистая бизнес-логика, она входит в модель..

Добавлю, что как Java-разработчику, у которого был большой опыт работы со Struts перед тестированием возможностей PHP, мне потребовалось некоторое время, чтобы понять, как применять идеи MVC к языку сценариев.я лично обнаружил, что используя такую ​​систему, как КодИгнитор очень помогло..он предоставляет основу, как и Struts, и поощряет хорошие шаблоны MVC.

Answer 5

Мой мир выглядит вот так:

DB1 <- Model1 для обеспечения доступа функции, целостность данных, бизнес правила для этого набора данных DB2 <- Модель 2 для обеспечения функций доступа, целостности данных бизнес-правил для этого набора данных

Контроллер :Управляет потоком данных в представлениях, фильтрует / упорядочивает данные из представлений.Реализует бизнес-правила для данного применение.Знает бизнес-правила между Модели.

Число просмотров:Не более чем шаблоны , которые отображают данные, предоставленные контроллером .Передайте все данные контроллеру .Нет сведений Model1 или звонит model2 или бизнес логики, которая ими правит.

Answer 6

Я рекомендую провести небольшое исследование шаблонов проектирования, поскольку это недостающая часть вашей головоломки.Существует ряд книг по PHP, посвященных этой теме (хорошие книги от APress), а также «библия» шаблонов проектирования: "Шаблоны проектирования:Элементы многоразового объектно-ориентированного программного обеспечения»

Answer 7

Подождем более стабильной версии Доктрина2.

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