Чи можна вільно з'єднати додаток із його рамками?

Скажімо, я розробляю веб-додаток. Мій перший вибір - використовувати PHP з Fat-Free Framework (F3) та MVC. У наступному році я можу вирішити, що хочу перейти на Zend Framework або, можливо, навіть ASP.NET MVC. Чи має сенс спробувати і розробити мою програму таким чином, щоб вона була слабко пов'язана з її рамкою, або рамка занадто цілісна, щоб зробити це реалістичним?

Єдина причина, про яку я прошу, - це те, що він нещодавно з'явився в розмові з однолітком, який розкритикував мою пиріг у небі, щоб вільно з'єднати мою програму з F3.

Вільно пов'язане додаток з його рамкою по суті означає, що ви збираєтеся написати рамку проксі. Написання цього проксі-сервера - це велика робота, і якщо ви коли-небудь переходите на новий фреймворк, вам доведеться зробити багато роботи, щоб проксі-сервер підтримував новий фреймворк. Звичайно, різні рамки використовують різні ідіоми та шаблони, що зробить проксі-сервер або дуже складним (якщо ви спробуєте зробити його підходящим до всього), або дуже обмеженим (якщо ви хочете за найнижчим загальним знаменником). У будь-якому випадку вам доведеться боротися з цим проксі-сервером.

Чи є можливість змінити рамки на примху, вартий усієї цієї неприємності? Як я вже говорив, ви не зможете змінити його на примху, тому що вам доведеться скорегувати проксі-сервер, що може виявитися більше справою, ніж безпосередньо коригування коду програми.

Нічого не може зробити.

Ви можете проектувати таким чином, щоб він був портативний у рамках. MVC - це MVC, і принципи приблизно однакові незалежно від мови та платформи.

Фактичний код, однак, буде дуже рамовим або залежним від мови. Єдиним способом абстрагуватися від цього було б кодування на основі проміжних рамок. Тоді ви можете мати проміжну зміну реалізації (з F3 на .NET?), Не змінюючи додаток. Це багато роботи, передбачає непропускні абстракції і просто переміщує проблему, не вирішуючи її: тепер ви прив’язані до свого проміжного плану.

З позитивнішої уваги: ​​розгляньте можливість вираження деяких своїх тестів (BDD стиль) на платформі, незалежної від вашої реалізації. Вони можуть пережити великі переписувачі.

Я одного разу бачив, як Роберт К. Мартін розмовляв, де він щось говорив у відповідь "перше рішення, яке ти приймаєш, - найскладніше прийняти згодом".

Тому моя порада - спробувати відкласти це рішення, якщо ви ще не зовсім впевнені, що хочете використовувати. Визначте фрагменти, які ви можете визначити зараз, і які легко залишатимуться незалежними від будь-яких рамок, які ви в кінцевому рахунку використовуєте.

Блокування за рамками може бути серйозною проблемою, але це допомагає розглядати проблему як одну з мобільності. Переносимість не є абсолютним атрибутом, але відносно вашого початкового пункту і куди, можливо, ви хочете піти. За аналогією, тоді програмне забезпечення є портативним лише в тій мірі, в якій ви вже перенесли його в інші середовища.

Більшу частину розробки програми всередині рамки має тенденція бути клейовим кодом, що поєднує компоненти вашої рамки разом. Файли конфігурації можуть абстрагувати певну кількість клею в деяких системах, але багато тонких деталей потрібно робити в коді.

З іншого боку, ділові правила та процеси можна абстрагувати від програми. Важка частина абстракції - це коли правила реалізуються безпосередньо рамками; безпека, доступність та послідовність процесів, як правило, забезпечуються вашими рамками, і це може бути найскладніше.

Якщо ви зможете відокремити клейову частину вашої програми від ділових правил та бізнес-процесів та частини бізнес-даних, ви зможете зробити деякі частини вашого рішення переносними.