アプリケーションをそのフレームワークに疎結合することは可能ですか？

Webアプリケーションを開発しているとしましょう。私の最初の選択肢は、Fat-Free Framework（F3）およびMVCパターンでPHPを使用することです。来年、Zend Frameworkに切り替えるか、ASP.NET MVCに切り替えることを決定するかもしれません。フレームワークに疎結合されるような方法でアプリケーションを設計しようとするのは理にかなっていますか、それともフレームワークがあまりにも統合されすぎて現実的ではありませんか？

私が尋ねる唯一の理由は、最近の仲間との会話の中で出てきたからです。仲間は、私のパイを空からF3に疎結合するというアイデアを批判しました。

アプリケーションをそのフレームワークに疎結合するということは、本質的にプロキシフレームワークを記述することを意味します。そのプロキシフレームワークの作成には多くの作業が必要です。新しいフレームワークに切り替える場合は、プロキシフレームワークが新しいフレームワークをサポートするようにするために多くの作業を行う必要があります。もちろん、異なるフレームワークは異なるイディオムとパターンを使用します。これにより、プロキシフレームワークは非常に複雑（すべてに適合させようとする場合）または非常に制限されます（最小公分母に向かう場合）。どちらにしても、そのプロキシフレームワークに苦労する必要があります。

このすべてのトラブルに見合う気まぐれでフレームワークを変更する機能を持っていますか？先ほど言ったように、プロキシフレームワークを調整する必要があるため、気まぐれに変更することはできません。これは、アプリケーションコードを直接調整するよりも手間がかかる場合があるためです。

できません。

フレームワーク間で移植可能な方法で設計できます。MVCはMVCであり、使用される言語やプラットフォームにかかわらず、原則はほぼ同じです。

ただし、実際のコードは、フレームワークまたは言語に大きく依存します。それから自分を抽象化する唯一の方法は、中間フレームワークに基づいてコード化することです。その後、アプリケーションを変更せずに、中間実装を変更できます（F3から.NETに？）。これは多くの作業であり、漏れのない抽象化を想定し、問題を解決せずに移動するだけです。これで、中間フレームワークに縛られます。

より積極的な注意事項として、実装に依存しないプラットフォームでテスト（BDDスタイル）の一部を表現することを検討してください。それらは大規模な書き換えを乗り切るかもしれません。

ロバートC.マーティンが「最初の決断は後で変えるのが最も難しい」という言葉に沿って何かを言ったという話を見たことがあります。

したがって、まだ何を使用したいかが正確にわからない場合は、この決定を遅らせることをお勧めします。現在定義できる部分、および最終的に使用するフレームワークに依存しない部分を特定します。

フレームワークのロックインは深刻な問題になる可能性がありますが、移植性の1つとして問題を見ることは役立ちます。移植性は絶対的な属性ではありませんが、出発点や、おそらく行きたい場所に関連しています。類推すると、ソフトウェアは既に他の環境に移植している場合にのみ移植可能です。

フレームワーク内でのアプリケーションの開発のほとんどは、フレームワークのコンポーネントを結合するグルーコードである傾向があります。構成ファイルは、システムによっては一定量の接着剤を抽象化する場合がありますが、多くの細かい詳細をコードで実行する必要があります。

一方、ビジネスルールとプロセスはアプリケーションから抽象化できます。抽象化の難しい部分は、フレームワークによってルールが直接実装される場合です。セキュリティ、アクセシビリティ、プロセスシーケンスは、フレームワークによって実施される傾向があり、最も見にくい場合があります。

アプリケーションの接着剤部分をビジネスルールとビジネスプロセスおよびビジネスデータ部分から分離できる場合、ソリューションの一部を移植可能にすることができます。