設計パターン-戦略ごとの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をモジュール化すると、この問題を解決できます。

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

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

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

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

C＃を介したAdaptive Codeの本では、著者はこのアプローチについて述べており、このような高レベルのデカップリングを提供するため、常に行う必要があることとして具体的に説明しています。（例）

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

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

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

私もそうします。

プロジェクト/ 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、アプリケーションのサイズ/複雑さが増加した場合にインターフェースをリファクタリングするのはかなり簡単です

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

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

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

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