可能な限りテクノロジーにとらわれないようにする必要がありますか？
フレームワークまたはツールを使用している場合、100％テクノロジーにとらわれないということはできません。常に、ツールまたはフレームワークに少なくとも20％依存します。
選択したテクノロジーにできるだけとらわれないことができれば、気分が良くなるということです。私の主な2つの理由は、将来作成されるより優れたツールに簡単に移行できることと、チームに参加する新しい開発者は、「フレームワーク」にそれほど依存していなければ、コードをすぐに理解できることです。
他の誰かが、私たちができる限りツールにとらわれないという正当な理由を持って来ることができますか？
ありがとう
これは非常に一般的な質問であるため、答えは必然的に「状況によって異なります」になる可能性があります。
例として、JPA（Hibernate）とEntity Frameworkは、（ほとんどがリレーショナル）データベースに対して抽象化を作成しようとする試みです。そのため、アプリは、実行されている実際のSQLデータベースエンジンに依存しません。
それは素晴らしいことですが、無料ではありません。得られるのは、より柔軟性があり（理論的には、基盤となるDBエンジンを切り替えることができます）、より優れた抽象化ですが、DBのより高度な機能を使用する可能性は失われます。よりよい性能。また、これらの抽象化はしばしば非常に「漏れやすい」ものです。置き換えられたDB（およびアプリ）は、おそらく古いものとは少し異なる動作をします。 SQLの機能、リレーショナルモデルの基本についてはまだ知っておく必要があります。したがって、初心者にとっては実際にはもっと難しい場合があります。SQLと選択したフレームワークの両方を知っている必要があります。
しかし、これはまだ完全に不可知論者ではありません。 JPA/EFは、やはり不可知論者になりたいテクノロジーの一部です。したがって、JPA/EFの上に独自のレイヤーを作成して、すべての実装の詳細（entitymanagers、dbcontextsなど）を隠します。
人々は通常、この目的のために既存のパターン（dao、リポジトリ）を採用します。新入社員は、SQL、JPA/EF、そして今やあなたの輝かしい新しいレイヤーを知る必要があります。
上記の状況は実際には非常に一般的ですが、「可能な限り不可知論的」とはほど遠いものです。また、リレーショナルモデル（NoSQL）でdbを使用し、dbがトランザクションとACIDをサポートしていると仮定するのをやめることもできます。そうすると、本質的に永続的なKey-Valueストレージのプログラミングモデルになります。あなたはあなたが失うものとあなたが得るものについて考える必要があります。
陪審員はまだこの質問に取り組んでいます。
どのように選択しても、コスト（結果）があります。
結果を分類して比較する方法はたくさんありますが、基本的な方法は次のとおりです。
- 開発コスト/生産性への影響
- 顧客が判断した製品品質への影響（欠陥の欠如や機能制限など）
- メンテナンスへの影響
- チームの能力-彼らがタスクに任されているかどうか。 「チーム」は流動的な概念であることを忘れないでください。人々は定期的にチームに参加したり、チームを離れたりします。 5年から10年後には、元のメンバーがチームに残っていない可能性があります。
- リスク
- 競争力-あなたの競争相手が何をするかに依存します。
- 中断-フレームワークプロバイダーが突然消滅するか、訴訟に見舞われる可能性があるかどうか、または契約/コードライセンスがいつでも終了する可能性があるかどうか
もちろん、このリストは網羅的なものではありません。
費用と便益を分析するときは、時間枠を割引に入れる必要があります。これは 経済学では「時間割引」/「時間優先」 として知られています。
言い換えれば、長期的には予測できない傾向があるため、短期的および短期的なトレードオフをより強く考慮する必要があります。