web-dev-qa-db-ja.com

デザインパターン-DLL戦略ごと

私は通常、次の方法でアプリケーションを設計していることに気づきました。

  1. 1つDLL希望するサブシステムのインターフェースを含む。たとえば、Company.Framework.Persistence.dll。
  2. 上記のサブシステムの各戦略（または実装）ごとに1つの新しいDLL）。例：
    • Company.Framework.Persistence.MSSQL.dll
    • Company.Framework.Persistence.MySQL.dll
    • Company.Framework.Persistence.FileSystem.dll

これにより、多くのプロジェクトで非常に大きなソリューションが得られますが、一方で、消費者はニーズに応じて適切なDLL）を選択する機会が与えられます。

単一のDLLと呼ばれるCompany.Framework.Persistence.dll、消費者は彼が決して使用しないかもしれない多くの戦略をロードしなければならないでしょう。モジュール化されているDLLこの問題を解決します。

これは良い習慣ですか？この設計には欠点がありますか？

designdesign-patterns.netproject-managementanti-patterns
8
Matias Cicero

このアプローチの長所は、短所をはるかに上回っていると思います。

ここで達成しているのは、IパターンによるSOLIDのStairwayの完全な「実装」です。つまり、アプリケーションによって異なりますCompany.Framework.Persistence.dllで定義されたインターフェースの「ダウン」および個々の実装自体も、この抽象化に「アップ」されます。

これは、アプリケーションが実装の詳細から大幅に切り離されていることを意味します（もちろん、通常は、IOCある種のコンテナーを使用して実際のランタイムグラフを作成する必要があります）。既存の画像に恥知らずにリンクしていますStack Overflowの主題に関する別の回答からのこのパターンの例：

Example of Stairway pattern

本の中で C＃による適応コード 作者はこのアプローチについて話し、特に常に実行する必要があるものとしてそれを呼び出しますそれはそのような高レベルのデカップリングを提供するからです。 （ 例 ）

別の考えられる利点は、他の実装に影響を与えることを心配することなく、個々の実装にパッチを適用できることです。ただし、これは回帰テストに精通した後は、かなりマイナーな実装です。また、必要なサードパーティの依存関係の特定のバージョンを含むことができるサブフォルダーに個々の実装を展開できることは、おそらくうまく整理するのに役立つでしょう。

このアプローチで私が考えることができる唯一の本当の欠点については、理論的にはCompany.Framework.Persistence.dllのインターフェイスを（アプリケーションのバイナリと共に）変更し、ランタイムにつながる対応する実装dllを更新することを無視できるということですユーザーのエラー。

過去にこれを正確に行うことで罪を犯してきたので、これは本当にあなたが非常に不注意な場合に起こり得ることだと言えます:)

3
Stephen Byrne

私もそうします。

プロジェクト/ dllは基本的に無料で、コードを読みやすく、使いやすくします。

私は人々が単一の大きなDLLを使用し、名前空間で区別することを知っています。しかし、彼らが未使用のコードを展開する必要があると言うように、私は実践への利点や多くの欠点などを見ていません。

  • 1つの実装に変更するには、他の実装を再コンパイルする必要があります
  • 未使用のコードがライブで展開されます（バグのリスク）
  • テストコードはライブでデプロイされます（モックなど、バグのリスク、設定ミス）
  • 廃止されたコードを削除するには、リファクタリングが必要です（たとえば、MySQLをもう使用しないとします）。
  • デプロイする前に未使用のコードをテストする必要があります（私たちは正しくテストしていますか？）
  • リファクタリングにより、未使用のコンポーネントでコンパイルエラーが発生する可能性があります（インターフェースを変更するとします）。

インターフェースが1つしか含まれていないプロジェクトを回避する場合は、小さなアプリケーションの場合、手抜きをして、具体的な実装をインターフェースに配置するかもしれません。しかし、通常、インターフェイスはモデルに対応しています。だから私は

  • Company.Framework.Models.dll（永続化のためのインターフェースを含む）
  • Company.Framework.Persistence.MySQL.dll（モデルを参照、とにかく必要がある）
  • Company.Framework.Persistence.Mock.dll（モデルを参照、とにかく必要がある）

または（悪いショートカット！）

  • Company.Framework.Models.dll（インターフェースを含まない）
  • Company.Framework.Persistence.MySQL.dll（永続化インターフェース、参照モデルを含む）
  • Company.Framework.Persistence.Mock.dll（モデルとSQLを参照しますが、実際にはデプロイされません）

Obvs、アプリケーションのサイズ/複雑さが増加した場合にインターフェースをリファクタリングするのはかなり簡単です

1
Ewan

戦略2の利点は、DLLの地獄を最小限に抑えることです。

通常、Company.Framework.Persistence.MySQL.dllは、MySqlとのインターフェースのためにいくつかのdllに依存します。 MySqlに関心がない場合、MySqlからDLLをダウンロードする必要があるのはなぜですか？

フレームワークが20の異なるストレージプロバイダーをサポートしていたとしましょう。ほとんどのユーザーは1つだけ使用します。したがって、すべてのユーザーは、フレームワークをコンパイルするためだけに使用する19個のDLLを取得および取得する必要があります。

戦略2を実行することで、ユーザーは使用するDLLのみをインストールできるため、DLLの地獄を最小限に抑えることができます。

0
Esben Skov Pedersen