Многоуровневый в PHP.. правильный путь?
Два подобных отражению решения, о которых я знаю с моих дней C++:
1) RTTI Использования, который предоставит начальную загрузку Вам для создания подобного отражению поведения, если Вы будете в состоянии заставить все свои классы происходить из 'объектного' базового класса. Тот класс мог предоставить некоторые методы как GetMethod, GetBaseClass и т.д. Что касается того, как те методы работают, необходимо будет вручную добавить некоторые макросы для украшения типов, которые негласно создают метаданные в типе для предоставления ответов на GetMethods и т.д.
2) Другая опция, если у Вас есть доступ к объектам компилятора, должен использовать DIA SDK. Если я помню правильно, что это позволяет Вам открыть pdbs, который должен содержать метаданные для Ваших типов C++. Могло бы быть достаточно сделать то, в чем Вы нуждаетесь. Эта страница показывает, как можно получить все базовые типы класса, например.
Оба они решение немного ужасны хотя! Нет ничего как немного C++, чтобы заставить Вас ценить роскошь C#.
Удачи.
7 ответов
Веб-приложения и 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, не переписывая уровень Business. Иногда это делается путем моделирования объектов для каждой таблицы (Table Gateway), каждая строка (активная запись), каждое соединение или каждая транзакция. Здесь что-то вроде PDO или PHP-ADO полезно, но недостаточно для полной изоляции. Уровни ORM / Persistence в Java, такие как Hibernate, лучше демонстрируют этот вид изоляции, часто предоставляя язык объектных запросов (OQL).
Я сам в настоящее время осуществляю переход от PHP-приложения на базе MySQL к MS. -SQL один. Приложение когда-либо использовало только прямые SQL-запросы. Представьте, что вы выбираете, как выполнять серию запросов в классе, и либо абстрагируя их, либо создавая подклассы и, надеюсь, не изменяя бизнес-логику. Как минимум, вы захотите сделать все свои вызовы SQL косвенными. ( Сообщение SO в PHP ORM .)
И, наконец, к вашему вопросу об ООП: используйте его так, как вы должны выполнять свои требования. Моя личная методика - начать с логики прямо в шаблоне презентации PHP на несколько минут, чтобы сдвинуть дело с мертвой точки, довольно скоро я реорганизую это в класс и шаблон. Если у меня есть общие идеи, я разбиваю подпрограммы на общие классы, стремясь сохранить принцип DNRY. (Сообщение SO об этом здесь. ООП не является фундаментальным требованием для N-уровневого дизайна. DNRY очень важен для поддержания вашего кода в сопровождении, тем не менее. Часто крайние сроки и сдвиг области действия разрушают API. пока вы не получите то, что вам нужно для продолжения работы. Готов поспорить, ООП поможет вам в этом.
стремясь сохранить принцип DNRY. (Сообщение SO об этом здесь. ООП не является фундаментальным требованием для N-уровневого проектирования. DNRY очень важен для поддержания вашего кода в сопровождении, тем не менее. Часто крайние сроки и сдвиг области действия разрушают API. пока вы не получите то, что вам нужно для продолжения работы. Готов поспорить, ООП поможет вам в этом. стремясь сохранить принцип DNRY. (Сообщение SO об этом здесь. ООП не является фундаментальным требованием для N-уровневого проектирования. DNRY очень важен для поддержания вашего кода в сопровождении, тем не менее. Часто крайние сроки и сдвиг области действия разрушают API. пока вы не получите то, что вам нужно для продолжения работы. Держу пари, ООП поможет вам в этом.I once read something saying that big models (business layer) should be preferred over big controllers (accessor layer).
Also: It really depends on the project. In my eyes it doesn't always make sense to use OOP for everything (probably not everyone will agree here), especially in scripting languages like PHP it oftentimes is easier to simply do validators as functions...
I definitely advise you not to have database calls in the presentation layer, that would defeat its purpose.
There are different approaches to multi-tier architecture and they have different recommendations.
Zend Framework that i've worked with is usually of the form Fat model/Thin controller variant.
If find this article Notes on Choosing a PHP Framework to be pretty good at comparing (in this case) CakePHP to Zend Framework.
The biggest difference in my opionion is the convention-over-configuration approach taken by CakePHP which is very different from configuration focus in Zend Framework.
By using a framework, which makes a lot of sense if implementing a multi-tier architecture, your are in a way forced or at least pushed into using OOP, which is not a bad thing.
You could of course implement, say a 3-tier architecture with pure functional calls, but it would not scale that well based on my experience.
For a website the MVC pattern which actually is quite different because of the way the tiers communicate, is a good choice.
The difference between a "normal" 3-tier arch and the MVC pattern is that the view has access to both the controller and the model layer, where as the presentation layer only has access to the logic layer of the 3-tier arch.
i agree with what Franz said, especially about preferring larger models over larger controllers.. you can also use a rule of thumb to help distinguish where code should go: if it has anything to do with the UI structure/flow, put it in the controller; if it's pure business logic, it goes in the model..
i'll add that as a Java developer that had a lot of experience with Struts before testing out the PHP waters, it took me a while to understand how to apply MVC ideas to a scripting language.. i personally found that using a system like CodeIgnitor helped a lot.. it provides the framework, much like Struts, and encourages good MVC patterns..
Мой мир выглядит так:
DB1 <- Model1 для предоставления доступа функции, целостность данных, бизнес правила для этого набора данных DB2 <- Model2 для предоставления функций доступа, данных честность, бизнес-правила для этого набор данных
Контроллер: Управляет потоком данных к просматривает, фильтрует / организует данные из Просмотры. Реализует бизнес-правила для данное приложение . Знает бизнес-правила между моделями.
Просмотры: не более чем шаблоны которые отображают данные, предоставленные Контроллер. Передайте все данные в контроллер. Не знает Model1 или Model2 или бизнес логика, которая ими управляет.
Я рекомендую исследуйте шаблоны дизайна, поскольку это недостающий фрагмент вашей головоломки. Есть несколько книг по PHP, которые охватывают эту тему (хорошие из APress), а также «библия» шаблонов проектирования: «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения»
Давайте подождем более стабильной версии Doctrine2 .
Она разрабатывается на основе философии объектов предметной области, игнорирующей персистентность. С помощью этого фреймворка будет намного проще разработать многоуровневое приложение.