DB レイヤーのクラスに静的関数しかないプロジェクトや、メンバー関数にアクセスするためにそれらのクラスをインスタンス化する必要がある他のプロジェクトを見てきました。
どちらが「より良い」で、その理由は何ですか?
DB レイヤーのクラスに静的関数しかないプロジェクトや、メンバー関数にアクセスするためにそれらのクラスをインスタンス化する必要がある他のプロジェクトを見てきました。
どちらが「より良い」で、その理由は何ですか?
私は、単一のオブジェクトをデータベース内の単一のレコードに関連付けるのが好きです。つまり、オブジェクトをインスタンス化する必要があります。これが基本的なActiveRecordパターンです。私の経験では、1 つのオブジェクトから 1 つの行へのアプローチは、コード内ではるかに流動的で読みやすい表現を作成します。また、オブジェクトをレコードとして、クラスをテーブルとして扱うのが好きです。たとえば、レコードの名前を変更するには、次のようにします。
objPerson = new Person(id)
objPerson.name = "George"
objPerson.save()
ルイジアナ州に住んでいるすべての人を取得するには、私ができるかもしれません
aryPeople = Person::getPeopleFromState("LA")
Active Record に対する批判はたくさんあります。特に、レコードごとにデータベースにクエリを実行している場合や、クラスがデータベースに密接に結合されている場合に問題が発生する可能性があり、両方に柔軟性がありません。その場合、レベルを上げてDataMapperのようなものを使用できます。
最新のフレームワークとORM の多くは、これらの欠点のいくつかを認識しており、それらに対するソリューションを提供しています。少し調べてみると、これは多くの解決策があり、すべてニーズに依存する問題であることがわかります。
それはすべて、DB 層の目的に関するものです。インスタンスを使用して DB 層にアクセスする場合、そのクラスの複数のバージョンが存在することを許可します。これは、たとえば、同じ DB レイヤーを使用して複数のデータベースにアクセスする場合に適しています。
したがって、次のようなものがあるかもしれません:
DbController acrhive = new DbController("dev");
DbController prod = new DbController("prod");
これにより、同じクラスの複数のインスタンスを使用して、異なるデータベースにアクセスできます。
逆に、アプリケーション内で一度に 1 つのデータベースのみを使用できるようにすることもできます。これを行いたい場合は、この目的のために静的クラスを使用することを検討できます。
lomaxx が述べたように、DB モデルの目的がすべてです。
通常は、DAL クラスのインスタンスを 1 つだけ作成する必要があるため、静的クラスを使用するのが最適です。複数回クエリできるインスタンスが 1 つだけ存在する必要がある場合に、DAL クラスのインスタンスを複数作成する可能性があるというオーバーヘッドに対処するよりも、静的メソッドを使用したいと考えています。
もうひとつの「場合による」。ただし、静的が機能しないという非常に一般的なシナリオも考えられます。かなりの量のトラフィックを取得する Web サイトがあり、共有接続を使用する静的データベース レイヤーがある場合、問題が発生する可能性があります。ASP.Net では、デフォルトでアプリケーションのインスタンスが1 つ作成されるため、静的なデータベース層がある場合、Web サイトを使用するすべてのユーザーに対してデータベースへの接続を1 つしか取得できません。
「DBレイヤー」に何をさせたいかによると思います...
データセットを返すストアド プロシージャまたは sql ステートメントを実行するための一般的なルーチンがある場合は、データセットを作成したオブジェクトへの永続的な参照が必要ないため、静的メソッドを使用する方が理にかなっています。
結果として厳密に型指定されたクラスまたはコレクションを返す DB レイヤーを作成した場合は、静的メソッドも使用します。
一方、ID などの特定のパラメーターを使用してクラスのインスタンスを作成し (@barret-conrad の回答を参照)、DB に接続して必要なレコードを取得する場合は、おそらくしたくないでしょう。クラスで静的メソッドを使用します。しかし、それでも、おそらく、他のクラスが依存していた静的メソッドを DID に持つ、ある種の DB ヘルパー クラスがあると思います。
サブスクライブするモデルによって異なります。ORM (オブジェクト リレーショナル モデル) またはインターフェイス モデル。ORM は、nhibernate、LINQ to SQL、Entity Framework などのフレームワークにより、現在非常に人気があります。ORM を使用すると、オブジェクト モデルに関するいくつかのビジネス上の制約をカスタマイズし、それをデータベースにコミットする方法を実際に知らなくても渡すことができます。挿入、更新、および削除に関連するすべての処理はオブジェクト内で行われるため、開発者はそれほど心配する必要はありません。
Microsoft によって普及したエンタープライズ データ パターンのようなインターフェイス モデルでは、オブジェクトがどのような状態にあり、どのように処理する必要があるかを知る必要があります。また、アクションを実行するために必要な SQL を作成する必要があります。
私はORMで行くと思います。