Допустим, я занимаюсь разработкой веб-приложения. Мой первый выбор - использовать PHP с Fat-Free Framework (F3) и шаблоном MVC. В следующем году я могу решить, что хочу перейти на Zend Framework или, может быть, даже ASP.NET MVC. Имеет ли смысл пытаться спроектировать мое приложение таким образом, чтобы оно было слабо связано со своей структурой, или эта структура слишком целостна, чтобы сделать это реалистичным?
Единственная причина, по которой я спрашиваю, состоит в том, что это недавно возникло в разговоре с коллегой, который раскритиковал мой пирог в небесной идее слабой связи моего приложения с F3.
design-patterns
object-oriented
frameworks
Big McLargeHuge
источник
источник
Ответы:
Слабая привязка вашего приложения к его фреймворку означает, что вы собираетесь написать прокси-фреймворк. Написание этого прокси-фреймворка - большая работа, и если вы когда-нибудь переключитесь на новый фреймворк, вам придется проделать большую работу, чтобы прокси-фреймворк поддерживал новый фреймворк. Конечно, в разных платформах используются разные идиомы и шаблоны, что сделает структуру прокси очень сложной (если вы пытаетесь приспособить ее ко всему) или очень ограниченной (если вы выберете наименьший общий знаменатель). В любом случае вам придется бороться с этой структурой прокси.
Стоит ли иметь возможность менять каркасы по прихоти всего этого? Как я уже сказал, вы не сможете изменить его по прихоти, потому что вам придется настраивать структуру прокси-сервера, что может оказаться более трудоемким, чем прямая настройка кода приложения.
источник
Не могу сделать.
Вы можете проектировать таким образом, чтобы это можно было переносить через фреймворки. MVC - это MVC, и принципы примерно одинаковы для любого языка или платформы.
Фактический код, однако, будет сильно зависеть от фреймворка или языка. Единственный способ абстрагироваться от этого - код, основанный на промежуточной среде. Затем вы можете изменить промежуточную реализацию (с F3 на .NET?) Без изменения приложения. Это большая работа, которая предполагает абстракции без утечек и просто перемещает проблему, не решая ее: теперь вы привязаны к своей промежуточной структуре.
На более позитивной ноте: рассмотрите возможность выражения некоторых ваших тестов (стиль BDD) на платформе, независимой от вашей реализации. Те могут пережить серьезные переписывает.
источник
Однажды я видел, как Роберт К. Мартин выступил с речью, в которой он сказал что-то вроде «первое решение, которое вы примете, будет самым трудным изменить позже».
Поэтому я советую отложить принятие этого решения, если вы еще не совсем уверены, что хотите использовать. Определите части, которые вы можете определить сейчас, и которые легко останутся независимыми от того, какой фреймворк вы в конечном итоге используете.
источник
Блокировка фреймворка может быть серьезной проблемой, но она помогает рассматривать проблему как проблему переносимости. Портативность не является абсолютным атрибутом, но связана с вашей отправной точкой и тем, куда вы, возможно, захотите пойти. Таким образом, по аналогии, программное обеспечение переносимо только в том случае, если вы уже перенесли его в другие среды.
Большая часть разработки приложения внутри фреймворка, как правило, представляет собой склеенный код, материал, который связывает компоненты вашей фреймворка. Конфигурационные файлы могут отвлекать определенное количество клея в некоторых системах, но многие мелкие детали должны быть сделаны в коде.
С другой стороны, бизнес-правила и процессы могут быть абстрагированы от приложения. Сложная часть абстракции - это когда правила реализуются непосредственно фреймворком; безопасность, доступность и последовательность процессов, как правило, обеспечиваются вашей средой и могут быть труднее всего увидеть.
Если вы сможете отделить связующую часть вашего приложения от части бизнес-правила, бизнес-процесса и бизнес-данных, вы сможете сделать некоторые части вашего решения переносимыми.
источник