Вернуться   SEO форум - оптимизация и продвижение сайтов > Web разработки > Программирование

Важная информация
Программирование - PHP, MySQL, JavaScript, CSS, HTML верстка и т.д.

Ответ
 
Опции темы Оценить тему Опции просмотра
Старый 14.04.2016, 23:43   #1
 
Аватар для wads
 
Сообщений: 261
FR (активность): 6,896

Доп. информация
Сообщение Автор темы Василий Безумкин. Работа на чистом PHP

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

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

Люди, уже программирующие на PHP, из этих уроков ничего нового не вынесут (ну, может что-то и подсмотрят любопытное, но не факт), так что курс будет интересен исключительно новичкам. Я рассчитываю на то, что вы знаете только базовые функции PHP и умеете писать простейший спагетти-код, то есть PHP вперемешку с HTML и выводом через echo().

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

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

Продажник: https://bezumkin.ru/training/course3/
Скрытый (как скрывать?) текст. Только для группы: "Пользователь":
Ваша группа не позволяет просмотреть скрытую информацию.


Хочешь поблагодарить используй кнопку спасибо
wads вне форума  
Сказавших "Спасибо!": 7 (показать список)
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
Старый 14.04.2016, 23:48   #2
 
Аватар для MVS
 
Сообщений: 544
FR (активность): 7,646

Доп. информация
По умолчанию

спасибо за мануалы!) Где б столько времени найти на изучение))
MVS вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
Старый 14.04.2016, 23:57   #3
 
Аватар для cthulchu
 
Сообщений: 3,659
FR (активность): 106,746

Доп. информация
По умолчанию

Вот это крутая штука. Наверное. Я бы тоже прочел, если бы было время. Но на каком-то этапе забил и взял фреймворк.
cthulchu вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
Старый 14.04.2016, 23:58   #4
 
Аватар для wads
 
Сообщений: 261
FR (активность): 6,896

Доп. информация
Сообщение Автор темы

Цитата:
Сообщение от MVS Посмотреть сообщение
спасибо за мануалы!) Где б столько времени найти на изучение))
ну собственно говоря на здоровье
надеюсь это кому то поможет изучить PHP
а на форуме появится множество спецов


Хочешь поблагодарить используй кнопку спасибо
wads вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
Старый 15.04.2016, 11:13   #5
 
Аватар для Hodge
 
Сообщений: 685
FR (активность): 14,957

Доп. информация
По умолчанию

Интересную статью вчера увидел. Сам пользуюсь вторым вариантом чаще чем первым.

Фреймворк vs сборка библиотек

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

Тут описаны основные различия, плюсы и минусы обоих подходов, и сферы их применения.

Начнем с основы.

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

Попробую развенчать этот культ. Сначала принципиальные отличия.

Схема фреймворка, это идеалистический подход к программированию. Где в основе лежит абстракция (душа), а детали бренны и должны ей подчиняться. Это следует из последнего принципа SOLID - DIP (Dependency inversion principle) Эта архитектура предполагает, что первичен фреймворк. Он "вбирает" в себя пользовательские скрипты (контроллеры, модели и пр) и рулит сам, предоставляя свои внутренние возможности. Инфраструктура фреймворка достаточно объемна.


Схема сборки представляет из себя простой набор компонентов и библиотек, не связанных с инфраструктурой. Обычно они просто структурированы в своих каталогах, и имеют различные интерфейсы. Её инфраструктура стремиться к нулю. Это материалистический подход. Первично тело, а душа, это что то такое из области химических процессов в мозгу. Но совсем без души нельзя - в окопах неверующих не бывает. )

.

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

В кодовом представлении основной принцип взаимодействия скриптов с библиотеками можно выразить так:

Фреймворк.

Код:
 <?php  

// ИНФРАСТРУКТУРА 
//////////////////////////////////// 
class Framework 
{ 
    public function __construct($controller) 
    { 
        $total = $controller->action(); 
        $lib   = new Librare; 
        $lib->render($total); 
         
    }    
} 
// Библиотека входит в инфраструктуру. 
class Librare 
{   // Этот метод должен быть обязательно 
    public function render($content) 
    { 
        echo $content; 
    }    
} 

//////////////////////////////////////// 
// ПОЛЬЗОВАТЕЛЬСКИЙ СКРИПТ 

class Controller 
{   // Этот пишется по правилам фреймворка 
    public function action() 
    { 
        return 'Соблюден принцип DIP'; 
    }    
} 

/////////////////////////////////////// 
// BOOTSTRAP 

// Пользовательский объект передается внутрь фреймворка 
(new Framework(new Controller));


Сборка.

Код:
<?php  

// ИНФРАСТРУКТУРА ОТСУТСТВУЕТ. ЕСТЬ ТОЛЬКО НАБОР БИБЛИОТЕК 
//////////////////////////////////// 

class Librare 
{   // Здесь никаких правил, может быть любой метод 
    public function render($content) 
    { 
        echo $content; 
    }    
} 

//////////////////////////////////////// 
// ПОЛЬЗОВАТЕЛЬСКИЙ СКРИПТ 

class Controller 
{   
    public function action() 
    {   // Используется выбранная библиотека 
        $lib = new Librare; 
        // По её правилам 
        $lib->render('Принцип DIP нарушен'); 
    }    
} 

/////////////////////////////////////// 
// BOOTSTRAP 

// Пользовательский скрипт запускается самостоятельно 
// Ну или минимальной инфраструктурой, допустим роутером  
(new Controller)->action();


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

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

А заслужено ли это? Давайте пройдемся по плюсам и минусам.

Фреймворк (плюсы)
1. Скорость и простота разработки приложений (пользовательских скриптов).
2. Некоторая унификация. Это больше касается мейнстримных фреймворков, так как их документация изучается многими специалистами. Но самоделок отчасти тоже. Основные принципы построения таких схем описаны в архитектурных паттернах, так что тем, кто вырос на этой схеме, разобраться не сложно.
3. Соответственно проще сопровождаемость (ну если конечно есть подробная документация)
4. Наложение ограничений на членов команды. Это важно, если персонал малоквалифицирован и не вызывает особого доверия. Тогда им легче ограничить "зону досягаемости".
5. Местами багоустойчивость. Фреймворки щедро заваливаются ексепшенами и другими механизмами защиты от дурака. Фреймворк сам и подсказывает, и страхует приложение от кривого кодинга. Это актуально при условии п.4
6. Коньюнктура. Поделку на фреймворке легче продать, так как считается, что для её сопровождения требуется менее квалифицированный, а значит более дешевый персонал.

Фреймворк (минусы)
1. Высокая ресурсоемкость. Так как инфраструктура получается достаточно большой, она требует накладных расходов.
2. Наличие непереопределяемого функционала. И хотя разработчики таких схем стараются достичь универсальности и расширяемости, то тут то там программисты впадают в ступор и не могут добиться желаемого от фреймворка.
3. Наличие "мертвого" функционала. Универсальные инструменты редко используются на 100%, но их сложность от этого не уменьшается.
4. Специфическе правила на грани собственного синтаксиса, что требует обилия сложной документации. Что отвлекает от кодирования продукта.
5. Зависимость. Так как основной принцип архитектуры фреймворка DIP, то библиотеки пишутся практически как плагины к нему. А значит это очень сильно снижает их переносимость.
6. Инкапсуляция. Да, да. Это минус в глобальном смысле. Разработчики приложений становятся заложниками разработчиков фреймворка. И не могут ни повлиять на него, ни защититься от багов, котоые могут допустить вторые.


Сборка (плюсы)
1. Низкая ресурсоемкость. Минималистическая инфраструктура и использование только необходимых библиотек резко снижает потребление ресурса сервера.
2. Гибкость на грани фантастики. Возможность использовать не только различные технологии без оглядки на "органы власти", но и даже различные парадигмы (мультипарадигмальность)
3. Чистота. Никакого "мертвого кода". Используются только востребованные приложением библиотеки.
4. Нативность кода. Нет никаких местечковых правил и суррогатного синтаксиса. Достаточно на хорошем уровне знать сам язык.
5. Возможность использовать любые библиотеки без адаптации. Ровно как и переносить кастомные, если они написаны по общепринятым правилам, не опасаясь нарушить правила интеграции в конкретный фреймворк.
6. Коллективная ответственность за код. Любые члены команды могут быть взаимозаменяемы. Нет деления на "фронт-энд" и "бэк-энд" на уровне серверных программ.
7. Ремонопригодность. Нет инфраструктуры - нет проблем. Не нужно бояться, что какой то баг завалит всю систему. Пользовательские скрипты и библиотеки по такой схеме достаточно дискретны и автономны.

Сборка (минусы)
1. Сложность разработки пользовательских скриптов. Так как функции инфраструктуры перекладыватся на них.
2. Повышенные требования к квалификации персонала. Нет ограничений, а значит должна быть персональная ответственность и самодисциплина.
3. Низкая ликвидность. Усилиями маркетологов фреймворки так распиарены, что и программисты (ай стыдно должно быть), и менеджеры стали бояться "чужого кода" и велосипедов.

Если внимательно сравнить эти две характеристики, то можно с удивлением заметить "зеркальность". Достоинства одной схемы, это недостатки другой. И наоборот. А это логично и закономерно. Потому что схемы эти равноправны, просто применяются для достижения разных целей.

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

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

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

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

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

Ну и так далее.

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

Источник: http://irbis-school.com/blog/full/44...orka-bibliotek
wads: сообщение полезно
Hodge вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
Старый 09.02.2017, 02:53   #6
 
Аватар для starlayt
 
Сообщений: 244
FR (активность): 5,781

Доп. информация
По умолчанию

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

Но ещё важно как писать. Например, все брезгуют написанием шаблонизатора и вёрстка перемешана с исполняемым кодом. Даже у популярных CMS. Итог: либо верстальщик должен знать язык движка (допустим, PHP), либо использовать софт (говнокод), либо работать в команде с программистом. Создание шаблонов становится долгим и неудобным занятием.

И таких нюансов множество. Экономия на разработке движка приводит к большим потерям человекочасов при написании под него дополнительного функционала (кто-то ещё поддержку модулей/плагинов/тем не делает, тогда вообще атас).
starlayt вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
"Плохо" от:
R.Romanov (19.10.2017)
Старый 18.10.2017, 22:02   #7
 
Аватар для nicfeer
 
Сообщений: 7
FR (активность): 40

Доп. информация
По умолчанию

Везде есть свои плюсы и минусы. фреймворк существенно сокращает время на написание кода, тогда как на чистом php писать будет дольше, но и чище.
nicfeer вне форума  
Ответить с цитированием Сказать Плохо за это бесполезное сообщение Быстрый ответ на это сообщение
"Плохо" от:
R.Romanov (19.10.2017)
Ответ

Метки
php

Быстрый ответ
Ваше имя пользователя: Регистрация. Для входа нажмите здесь
Случайный вопрос

Сообщение:
Опции


Опции темы
Опции просмотра Оценка этой теме
Оценка этой теме:

Ваши права в разделе
Вы не можете создавать новые темы
Вы можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Нужна работа (выполню любую рутинную работа за Вас) xxxDanielxxx Контент-менеджеры 0 20.08.2015 15:45
Работа, работа и еще раз работа. Чем заняться в свободное время на работе? Fldr Интернет 20 03.04.2015 23:45
[ Вопрос ] Оптимизация меню сайта на чистом html markaus Раскрутка в общих чертах 4 28.07.2013 15:08

Текущее время: 00:41. Часовой пояс GMT +3.