PHP: личная структура

Question

Я собираюсь написать фреймворк для моих веб-проектов на PHP. Пожалуйста, не говорите мне о том, чтобы подумать об использовании какой-либо существующей платформы (Cake, CodeIgniter, Symfony и т. Д.) - я уже посмотрел их и решил написать для себя.

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

Под модульной системой я подразумеваю, что каждый модуль имеет ровно один PHP-файл и один или несколько шаблонов, связанных с ним. Примером модуля будет modules/login.php, который использует templates/login.tpl для своего дизайна.

В наши дни все (?) Говорят о концепции MVC (Model View Controller), и большинство существующих платформ тоже используют ее.

Итак, мои вопросы следующие:

• Действительно ли MVC эффективен для личной структуры?
• Было бы плохой идеей использовать модульную систему?
• Вы когда-нибудь писали рамки для себя? Каковы ваши переживания?

Answer 1

Действительно ли MVC эффективен для персональной структуры?

Да, это может быть. Хотя, это может быть немного излишним (что не обязательно плохо, если вы пытаетесь учиться)

Было бы плохой идеей использовать модульную систему?

Это никогда не плохая идея.

Вы когда-нибудь писали рамки для себя? Каковы ваши переживания?

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

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

Answer 2

Действительно ли MVC эффективен для персональной структуры?

Что MVC означает больше из-за его расплывчатой ​​интерпретации, так это бизнес-логика, представление и обработка ввода. Таким образом, если вы не собираетесь разрабатывать приложение, которое не включает в себя три из них, MVC, в его смутном смысле, очень подходит.

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

В долгосрочной перспективе то, о чем просит MVC, выгодно для устойчивости приложения с точки зрения обслуживания, модификации или дополнения. Вы не хотите пропустить это. Однако не все системы поощряют правильную практику. Я не удивлен, что вы нашли различные реализации, которые вы пробовали недостаточно. Мой личный фаворит - Агави. Мне и другим, в мире PHP-фреймворков, которые не чувствуют себя хорошо, Agavi появляется, чтобы делать правильные вещи. Агави стоит того.

Было бы плохой идеей использовать модульную систему?

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

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

Вы когда-нибудь писали рамки для себя? Каковы ваши переживания?

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

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

Причина, по которой я думал, что смогу сделать это правильно, не в том, что все гайки и болты каркаса были неправильными.На самом деле, я ничего не знал о том, насколько они правы или неправы, потому что никогда не работал с ними.То, с чем я работал, было эмалью, и это чувствовало себя вялым.Самый быстрый способ получить свою собственную конструкцию - это украсть гайки и болты у другого и создать собственную эмаль.Это то, что вы видите при создании приложения, и, честно говоря, это единственная часть, которая имеет значение.Все остальное - пустая трата вашего времени в шаблоне.Однако, чтобы научиться создавать программное обеспечение, это не пустая трата времени.

Если у вас есть другие вопросы, пожалуйста, задавайте.Я рад ответить со своим собственным опытом.

Answer 3

• Действительно ли MVC эффективен для персональной структуры?
• Было бы плохой идеей использовать модульную систему?

Да, это так. Но MVC - это такой лёгкий шаблон проектирования, что вы можете провести границу между моделью, видом и контроллером где угодно. Для меня наиболее важными частями являются модель и вид. У меня просто есть страницы, модули php, которые генерируют html, заполняя шаблон из базы данных. Страницы - это представление, а база данных - модель. Любой общий специфичный для приложения код может быть разложен на «контроллеры». Примером может служить общий сложный запрос, который несколько страниц должны использовать для визуализации данных.

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

• Вы когда-нибудь писали рамки для себя? Каковы ваши переживания?

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

Некоторые указатели (0x912abe25 ...):

Каждая абстракция имеет свою стоимость.

Не думай. Вы могли бы сожалеть, что не сделали это простым. Добавьте только правильное количество абстракции. Вы можете найти себя чрезмерно абстрактным, и что-то, что должно быть простым, стало чрезмерно сложным. Я знаю, что сделал эту ошибку. Помни, Ты не нуждаешься в этом.

Хорошо определите ваши переменные

Не загружайте свои страницы, выполнив

      include_once('...page file ...');

где ожидается, что файл подкачки будет иметь встроенный php для выполнения поиска различных глобальных переменных. Вы теряете чувство простора. Это может стать неприятным, если вы загрузите файл подкачки из функции:

      function processCredentials()
      { 
           if (credentialsFail)
           {
                 include_once('loginpage.php');
           }
      }

Кроме того, когда дело доходит до области видимости, обрабатывайте все, что включено в шаблоны, как переменные с областью видимости. Будьте внимательны, если вы заполняете шаблоны из чего-либо, находящегося за пределами файла подкачки, связанного с этим шаблоном (например, из основного index.php или чего-то еще) Когда вы делаете это, неясно, что именно для вас заполнено и что требуется для подключения к шаблону.

Не перегружайте свою базу данных OO.

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

Для более сложных запросов не уклоняйтесь от SQL. Используйте простые абстракции, чтобы гарантировать дезинфекцию и проверку ваших входных данных. Не сходите с ума от абстрагирования базы данных. ПОЦЕЛУЙ.

Answer 4

Я также пишу фреймворк для php с моим другом. Я абсолютно понимаю, что ты делаешь.

Я думаю, что ты делаешь рядом с MVC. У вас есть шаблоны как представления. И модули в качестве контроллера. Так что я думаю это нормально. Единственное, что вам нужно, это модель. Это были бы какие-то активные записи.

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

Я вижу только одну проблему, которую вам нужно решить. Рамки должны быть идеально интегрированы. Всегда сложно сделать так, чтобы ваш модуль выглядел хорошо интегрированным, не думая о модуле, пока вы пишете приложение.

Answer 5

Я переработал большой PHP-проект, чтобы сделать его более совместимым с MVC.

Я нашел особенно полезным создание слоя DAO для централизации всех обращений к базе данных. Я создал функцию daoFactory, которая создает DAO и внедряет в нее дескриптор базы данных (также вводится logger, я использовал log4php).

Для DAO я использовал много функций базы данных (mysql), таких как хранимая процедура и триггеры. Я полностью согласен с Дагом Т. о том, чтобы избежать чрезмерной абстракции, особенно для доступа к базе данных: если вы правильно используете БД (подготовленные операторы и т. Д.), Вам не нужен ORM, и ваш код будет намного быстрее. Но, конечно, вам нужно изучить mysql (или postgress), и вы становитесь зависимыми от него (особенно если вы используете много хранимых процедур, как я обычно).

В настоящее время я делаю рефакторинг на шаг дальше, используя фреймворк Slim php и переходя к перезаписывающему API: в этом случае больше нет представления, потому что все выводится как json. Но я все еще использую smarty, потому что его кэширование работает хорошо, и я это знаю.

Answer 6

Написание основы может быть полезным опытом. Важно учитывать, что вы не пишете рамки для себя. Причина, по которой пишут фреймворк, заключается в том, чтобы упростить разработку.

Поскольку это личная структура, вам следует подумать о том, как она может помочь вам развиваться с меньшими хлопотами.

Я не считаю систему шаблонов хорошей идеей. Подумайте об этом - в чем главное преимущество использования системы шаблонов? Ответ заключается в том, что это помогает командам с различными наборами навыков совместно разрабатывать приложения. Другими словами, некоторые члены команды могут работать над пользовательским интерфейсом, и им не обязательно быть PHP-программистами. Теперь, скорее всего, личный каркас будет использоваться одним человеком, и выгода от использования системы шаблонов становится неактуальной.

В общем, вы должны взглянуть на свои собственные привычки и методы кодирования и найти задачи, которые занимают большую часть вашего типичного проекта. Затем вы должны спросить себя, как вы можете автоматизировать эти задачи, требуя меньше времени и усилий. Реализуя эти механизмы автоматизации, вам придется придерживаться каких-то соглашений (аналогично API). Сумма вспомогательных механизмов и соглашений будет вашей личной структурой.

Удачи.

Answer 7

Я бы сказал, что MVC имеет для меня больше смысла, поскольку он чувствует себя лучше, но единственное практическое отличие состоит в том, что ваш login.php будет содержать как модель (определения структуры данных), так и контроллер ( код для действий на странице). Вы можете добавить один файл в модуль, например, class.login.php и используйте для этого __autoload(), что по существу будет реализовывать структуру MVC.

Answer 8

1. MVC не работает
2. вы не хотите быть ограниченным в структуре ваших "модулей"; также держите шаблоны близко к коду (каталог templates - плохая идея)
3. нет

re 1 .: см. Holub Аллена Холуба по шаблонам. Вкратце: MVC в основном требует от вас отказаться от объектно-ориентированных принципов.

Tell Don't Ask - это броское имя для умственного трюка, который помогает вам хранить данные и код, которые действуют на него вместе . Представления приводят к тому, что Model превращается в кучу геттеров и сеттеров, с небольшим количеством каких-либо значимых операций, определенных для них. Код, который естественно принадлежит к Model , затем на практике распределяется между Controllers и Views (!), Создавая нездоровое Дистанционное действие и жесткую связь.

Объекты модели должны отображаться сами, возможно, с использованием какой-либо формы внедрения зависимостей:

interface Display
{
    function display($t, array $args);
}

class SomePartOfModel
...
{
    function output(Display $d)
    {
        $d->display('specific.tpl', array(
            'foo' => $this->whatever,
            ...
        ));
    }
}

OTOH, на практике большинство веб-приложений требуют другого архитектурного паттерна, где Model заменяется Services . Активная база данных, нормализованная схема и специфичные для приложения представления имеют большое значение: вы сохраняете вместе данные и код, которые на них действуют , а декларативный характер делает его намного короче того, что вы могли бы сделать в PHP.

Хорошо, так что SQL - ужасно многословный язык. Что мешает вам создать его из какого-то лаконичного DSL? Имейте в виду, я не обязательно предлагаю использовать ORM. На самом деле совсем наоборот. Без Model в любом случае ORM практически бесполезен. Возможно, вы захотите использовать что-то для построения запросов, хотя это должно быть очень просто, возможно, до такой степени, что вам не понадобится такой инструмент ...

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

Большинство веб-приложений являются не только владельцами соответствующих баз данных, но и их единственными потребителями. Несмотря на этот факт, большинство веб-приложений получают доступ к своим данным через неуклюжие интерфейсы: либо нормализованную схему, простую схему, либо денормализованную схему, которая, как оказалось, облегчает одну операцию за счет серьезного дискомфорта в других местах (различные столбцы в стиле csv и т. Д.) , Это немного грустно и без нужды.

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

Шаблоны

должны храниться близко к коду, который их использует, по той же причине, по которой код, работающий вместе, должен храниться вместе. шаблоны представляют собой форму кода, V в MVC. Вы хотите, чтобы детализированные шаблоны позволили (повторно) использовать. нет причины, по которой уровень представления не должен быть таким СУХИМЫМ, как другие части кода.