オブジェクトを構築して返す Factory クラスを作成しています。私は通常、データ アクセス レイヤーですべてのデータ処理を行いますが、目的を達成できるとは思いません。私がやりたいことは、SQLDataReader を使用してデータ情報をすばやく読み取り、ファクトリから返されるオブジェクトを設定することです。これはばかげた考えですか?より良いアプローチはありますか?可能であれば、DAL から DataSet を返さない方がいいですか、それともパフォーマンスと保守性の問題ですか?
3 に答える
ほとんどの場合、これは良い考えです。この方法には 2 つの大きな利点があります。
このようにして、データ アクセスとビジネス ロジックを分離できます。つまり、データベースの設計を変更しても、上位層のアルゴリズムを変更する必要はありません。
オブジェクト指向の観点からは、一部の純粋なデータをオブジェクトに変換し、オブジェクトに動作を追加することもできます。これにより、コードの保守と再利用が容易になります。
Factoryの予想される使用法に依存すると思います。これがデータ アクセス レイヤーのファクトリであり、ビジネス オブジェクトにデータベースからのデータを入力するために使用される場合、はい、ここでそれを行います。( IRepositoryパターンはこのようなものです...一種の)。
あなたの工場があなたのデータアクセスコードの近くに住むつもりがないなら、私はそれらを分けておきます. 単一責任の原則を忘れないでください。オブジェクトには、変更する理由が 1 つだけある必要があります。ファクトリがオブジェクトにデータを入力するだけの場合は適切な使用法ですが、他の処理に加えてオブジェクトにデータを入力する場合は、データを追加しないことをお勧めします。
どちらの方法でもトレードオフがあるので、一般的に、私はオブジェクトをできるだけシンプルに保ちたいと思っています。
SQLDataReader からロードしたすべてのデータを使用することが確実な場合は、工場での構築時にそれを行うことができます。ただし、データ セットに多くのフィールドがあり、そのうちの少数しか使用されない場合は、アクセサーが呼び出されたときにデータをデマンド ロードする方がリソースをより有効に使用できます。
とはいえ、すべての「ピース」が手元にあるときに工場にロードすることをお勧めします。正確に正しくない場合は、修正が必要なものがわかります。常に、機能する可能性のある最も単純なものから始めてください。