あなたの直感はすべて正しいと思います。
いいえ、ありません。静的またはインスタンス。
それはデザインの選択です (そしてそこにはたくさんあります)。私は実用主義者なので、スパゲティ コードを生成するデザイン パターンは悪いデザイン パターンの選択だと考えています。しかし、あるプロジェクトの悪いデザイン パターンが、別のプロジェクトの良いデザイン パターンになることもあります。Head First Design Pattern の本を読んでみてください。
はい、インターフェースと抽象クラスがあります。
さらにいくつかの考え：
静的メソッドやクラスの使用を避ける必要はないと思います。回避しなければならないのは、言語内のすべてを誤って使用するのと同様に、静的メソッドまたはクラスを誤って使用することです。しかし、static の誤った使い方を定義することは非常に難しく、static メソッドやクラスは特に危険であるため、static キーワードをまったく使用しないように言うのが好きです。アプリケーションを終了しない限り、静的メソッドはメモリ内にあるため、静的メソッド内で接続を破棄しないと、非常に悪い日になります。
ユーティリティ プロジェクトがあり、ユーティリティ プロジェクト内にデータ クラスがあります。データ クラスは、データベースへのアクセスを提供します。静的クラスです。なんで？
まず第一に、接続文字列は webconfig から取得されるため、静的です。したがって、webconfig を読み取り、静的プライベート メンバー変数に文字列を格納する静的コンストラクター (アプリケーションの起動時に一度実行され、クラスが言及される) があります。webconfig ファイルを読み込んで、スコープ付き変数を 1 日 100 億回作成するよりもはるかに優れていると思います。メソッドは十分に単純であるため静的です。つまり、機能するために多くの構成は必要なく、いくつかのパラメーターのみが必要であり、データ アクセス プロジェクトでのみ使用されます。私のウェブサイトのすべてのユーザーはメソッドの同じインスタンス (静的メソッド) を使用していますが、全員が異なるパラメーターで静的メソッドを使用しているため、異なる応答が得られます (パイプを共有していますが、飲む水は異なります)。これ' メソッド内で必要なのは、すべてをクリーンアップする (すべてのスコープ インスタンスを破棄する) ことだけです。そして最後に、私のビジネスはデータ操作に関するものです。非静的データ クラスは、静的データ クラスよりもはるかに多くのメモリ使用量を意味します (CPU 使用量は両方のパターンでほぼ同じです)。
public abstract class Data
{
[...]
static Data()
{
#if DEBUG
_Connection = ConfigurationManager.AppSettings["debug"];
#endif
#if RELEASE
_Connection = ConfigurationManager.AppSettings["release"];
#endif
[...]
}
[...]
}
結局のところ、次の場合に static を使用します。
- それが十分に単純である場合（すべての側面を制御できる場合）;
- それが十分に小さい場合（検証に拡張メソッドを使用し、それらは静的です）および;
- 使用頻度が高い場合。
それに加えて、プロジェクトを整理するためにレイヤーを使用します (poco + factory パターン)。ユーティリティ プロジェクト、エンティティ モデル プロジェクト、アクセス プロジェクト、ビジネス ロジック プロジェクト、Web サイト、API、マネージャーなどがあります。ユーティリティ プロジェクト内のクラスは相互に対話しませんが、エンティティ モデル プロジェクト内のクラスは相互に対話します (クラスはその中に別のクラスのインスタンスを持つことができます)。エンティティ モデル プロジェクトはユーティリティ プロジェクトと対話しません。それらは同じレベルを持ち、アクセス プロジェクトの別のレベルで相互に対話するためですが、データ操作プロジェクトではより直感的です。