Блог


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

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

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

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

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

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

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



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

.

 

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

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

Фреймворк.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
<?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));


 


Сборка.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?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. Низкая ликвидность. Усилиями маркетологов фреймворки так распиарены, что и программисты (ай стыдно должно быть), и менеджеры стали бояться "чужого кода" и велосипедов.

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

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

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

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

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

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

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

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

 

  Рекомендую ознакомиться:

1. Multi threaded design guidelines for libraries
2. Фреймворки, библиотеки и зависимости
3. Фреймворк
4. Библиотечные паттерны: Почему фреймворки — это зло


Теги: PHP | Флейм

Комментарии (0)


 
Наверх