1

いくつかのAPIを表すライブラリのセットを想像してみてください。制御メカニズムの反転を使用することにより、具体的な実装が消費プロジェクトに注入されます。

これが状況です。特定の機能について他のAPIライブラリに依存するAPIライブラリがいくつかあります。したがって、APIライブラリ自体はある時点で結合されます。1つのAPIを変更すると、依存するAPIも変更され、対応する実装も変更する必要があるため、この結合は後で問題になる可能性があります。最悪の場合、かなりの数のプロジェクトが必要になります。そのうちの1つだけからの変更を反映するように変更されました。

今、私はこれに対して2つの可能な解決策を考えています：

  • 関連するAPIライブラリを統合するモノリスAPIプロジェクトを作成します。

  • 各ライブラリが他のAPIに依存するすべての機能のインターフェイスを提供するようにすることで、APIをさらに分離し、直接の依存関係を削除します。これにより、両方のライブラリで同様のコードが生成される可能性がありますが、IoCメカニズムを介して選択された実装に自由が与えられ、APIが互いに独立して改善できるようになります（APIが変更された場合、変更はその実装ライブラリにのみ影響し、他のAPIまたはその実装）。

2番目のアプローチの問題はコードの複製であり、その結果、参照する必要のあるAPIライブラリが多すぎる可能性があります（たとえば、.NETアプリケーションでは、各APIは個別のDLLになります。Silverlightなどの一部のシナリオではアプリケーションの場合、これはアプリのサイズ（ダウンロード時間とクライアントのパフォーマンス全体）の問題になる可能性があります。

状況に対するより良い解決策はありますか？いくつかのAPIライブラリを1つの大きなものにマージする方が良い場合とそうでない場合はいつですか？これは私が尋ねている非常に一般的な質問ですが、期限、見積もり、クライアントの要件、テクノロジーを少し無視して、最大のスケーラビリティと最小のメンテナンス時間の両方を達成することに基づいて適切なアプローチを決定できるようにしたいと思います。それで、どちらかのアプローチ、またはあなたが私に提案するかもしれない別のアプローチを選ぶ良い理由は何でしょうか？

編集：

その質問について何かを明確にしなければならないような気がします。APIを実装から分離するのではなく、APIを相互に分離することを念頭に置いています。したがって、たとえば、アクセス許可を検証するためのセキュリティAPIと、セキュリティAPIを使用（参照）するユーザーアカウントAPIがある場合、セキュリティAPIを変更すると、ユーザーアカウントAPIとその両方の実装を変更する必要があります。このように結合されるAPIが多いほど、より多くの変更を適用する必要があります。それは私が避けたいものです。

4

3 に答える 3

4

選択は、いくつかの巨大なライブラリと無数の小さなライブラリの間です。

  • 巨大なライブラリがある場合、緩く結合された方法でさまざまな要素を設計するための圧力を提供する力がないという理由だけで、内部のコードは密に結合される傾向があります。調整しなければならない相互依存関係が非常に多いため、そのライブラリを進化させることがますます難しくなるというリスクがあります。例として、.NET基本クラスライブラリについて考えてみてください。
  • あなたが無数の小さなライブラリを持っているなら、あなたはdll地獄の危険を冒すかもしれません。はい、私たちは何年も前にこれが終わったと約束されましたが、そうではありません。アプリケーションコードベースで多くのきめ細かいオープンソースライブラリを使用してみてください。そうすれば、私が何を意味するのかがわかります。

それでも、単一責任の原則はパッケージレベルにも適用されるため、巨大な汎用ライブラリではなく、小規模で焦点を絞ったライブラリをお勧めします。これにより、常に最高のライブラリを簡単に選択できるようになります。

小さなライブラリはいつでも大きなライブラリに構成/コンパイルできますが（.NETではAssembly Linker / Merger / Repackerユーティリティを使用）、大きなライブラリを分割するのははるかに困難です。

何をするにしても、覚えておくべき最も重要なことは下位互換性です。導入する重大な変更が少ないほど、それらのライブラリの管理が容易になります。

于 2012-02-02T21:21:23.567 に答える
1

私はこれを問題とは思っていません。一部のライブラリは他のライブラリに依存しますが、これは私にとっては問題ありません。1つのライブラリを改善すると、すべての依存関係が改善されます。ライブラリの「所有者」は、変更を加えるときに既存のコードを壊さない責任がありますが、これは正常であり、コードが適切に設計されていれば簡単に処理できます。

于 2012-02-02T14:09:08.243 に答える
1

依存するすべてのコードに波打つような変更がある場合は、設計を再検討する必要があります。ライブラリが特定のAPIを表示する場合、そのコンシューマーを基になるクラスまたはライブラリへの変更から分離する必要があります。

アップデート1：

アプリケーションがAPI1でLibrary1を使用する場合、Library1がLib2、Lib3、..、LibXを使用するという事実に対処する必要はありません。

たとえば、MoqモックライブラリはCastleDynamicProxyに依存しています。なぜあなたはそれを気にしなければならないのですか？DynamicProxyがすでにマージされているアセンブリを取得し、Moqを使用するだけです。DynamicProxyを見たり、使用したり、気にする必要はありません。したがって、DP APIが変更されても、Moqを使用して作成されたテストには影響しません。Moqは、基盤となるDPのAPIの変更からコードを分離します。

アップデート2：

複数のブランチに有効な問題を見つけると、それらすべてが変更されます

その場合は、ライブラリを作成するのではなく、他のプロジェクトに強制されてはならない非常に具体的な問題のヘルパーを作成します。共有ライブラリは、「遠い将来のどこかで役立つかもしれない」というコレクションに退化する傾向があります。しないでください！これは常にa**であなたを噛みます！複数の場所（Guardクラスなど）で発生する問題の解決策がある場合：それを共有します。問題の解決策が見つかるかもしれないと思われる場合は、実際にその状況になるまでプロジェクトに残してください。次に、それを共有します。「万が一に備えて」決してそれをしないでください。

于 2012-02-02T14:32:39.443 に答える