問題タブ [data-access-layer]

市場のエンティティ フレームワークである LINQ2SQL を使用する場合、エンタープライズ ライブラリ データ アクセス アプリケーション ブロックを使用してデータ アクセス レイヤー (DAL) を設計することは理にかなっていますか?

ありがとう。

どんな種類のORMツールも許可しないITショップにいるとしましょう。彼らはそれを購入したくないし、あなたもオープンソースソリューションを使うことができません。

あなたならどうしますか？実際のドメインモデルをあきらめて、テーブル中心で作業しますか？独自のDALを作成しますか？

3 番目のモンキー アプローチ ( http://www.codeproject.com/KB/database/DynamicMethod_ILGenerator.aspx )のバリエーションを使用して、データリーダーから汎用エンティティを設定するデータ アクセス レイヤーを実装しました。これはうまく機能し、うまく機能し、データ取得のために何度も繰り返しコードを書く必要がなくなりました。

ここで、ジェネリック エンティティを受け取り、ストアド プロシージャにフィードするためのパラメーター リストに変換するメソッドを追加して、サルのトリック コレクションにデータの永続性を追加したいと考えています。

http://msdn.microsoft.com/en-us/library/ms973259.aspxでいくつかのガイダンスとautosproc ソリューションのサンプル コードを見つけました。紙の上では見栄えがよく、これを組み込むつもりですが、autosproc を実装するユーザーエクスペリエンスの点で簡単なグーグルはあまり現れませんでした。すでに。

では、autosproc を使用したことがありますか? うまくいきましたか？パフォーマンスなどに、エンタープライズ アプリケーションに適さない大きな欠陥はありますか?

アドバイスをいただければ幸いです。

私は、計画の形で患者情報を追跡するために、ソーシャル ワーカーと看護師のチーム (2 ～ 4) によって主に使用される、時々接続された CRUD アプリケーションに取り組んでいます。このアプリケーションは、私の時代より前に作成された ASP.Net アプリを再視覚化したものです。4 つのデータベースにまたがる約 200 のテーブルがあります。Web アプリ バージョンは SP に大きく依存していましたが、このバージョンはローカル データベースを指す winform アプリであるため、SP を使用し続ける理由はありません。また、同期部分を処理するためにマージ レプリケーションを使用することを計画していましたが、これら 2 つを一緒に使用すると問題が発生するようです。

DAL に使用するアプローチを理解しようとしています。私は当初、LINQ to SQL を使用する予定でしたが、ときどき接続設定では機能しないというちょっとした情報を読みました。したがって、私は多くの解決策を読んで実験しようとしています。サブソニック、NHibernate、エンティティ フレームワーク。これは比較的単純なアプリケーションであり、「迫り来る」バージョン 3 の再設計により、この取り組みは「使い捨て」の境界線になる可能性があります。ここでの重点は、デスクトップ バージョンをできるだけ早く起動して実行することです。

ここで私が求めているのは、これらの技術 (または私がリストしていない技術) のいずれかを使用した経験がある人なら誰でも、苦労して得た知恵を貸してくれることです。あなたの意見では、私が追求する最善のアプローチは何ですか. この種のアプリの作成に関するその他の洞察はありますか? このプログラムの DAL 部分に本当に苦労しています。

ありがとうございました！

これを行うための最もクリーンな方法を見つけようとしています。

現在、私は顧客オブジェクトを持っています:

次に、私の Email オブジェクトもかなり基本的なものです。

DataAccessLayer は現在データベースに接続しており、SqlDataReader を使用して結果セットを反復処理し、新しい Email オブジェクトを作成して、完了時に返される List に追加します。

では、これをどこでどのように改善できますか？

代わりに DataAccessLayer に DataTable を返させ、それを Email オブジェクトに任せて解析し、List を顧客に返す必要がありますか?

「Factory」はおそらく間違った言葉だと思いますが、DataAccessLayer から DataTable を取得し、リストを Email オブジェクトに返す別のタイプの EmailFactory を使用する必要がありますか? 私はそのようなことは冗長に聞こえると思います...

私の Email.getEmails(id) を静的メソッドとして使用することは、これでも適切な方法ですか?

通常は単純なタスクに最適な「パターン」を見つけて適用しようとすることで、私は自分自身を捨てているだけかもしれません.

ありがとう。

ファローアップ

ドメイン/ビジネス オブジェクトが既存のデータベースから ID で顧客レコードを抽出する実際の例を作成しました。nhibernate の xml マッピング ファイルは非常に優れています。チュートリアルに従ってセッションとリポジトリ ファクトリをセットアップした後は、データベース レコードのプルは非常に簡単でした。

ただし、パフォーマンスが大幅に低下していることに気付きました。

私の元のメソッドは、結果セットをドメイン/ビジネス オブジェクトに解析する DAL オブジェクトによって呼び出される DB 上のストアド プロシージャで構成されていました。

1 つの顧客レコードを取得するのに 30 ミリ秒かかる元の方法を記録しました。次に、同じレコードを取得するのに 3000 ミリ秒かかる nhibernate メソッドのクロックを記録しました。

何か不足していますか？それとも、この nhibernate ルートを使用すると、多くのオーバーヘッドが発生しますか?

それ以外の場合は、コードのクリーンさが気に入っています。

私が従った例では、セッションを管理するのに役立つヘルパー クラスを作成しました。

私が取り組んでいるアプリケーションでは、速度が重要です。そして最終的には、Web アプリとデータベースの間で大量のデータがやり取りされます。エージェントが顧客レコードを取得するのに 3 秒ではなく 1/3 秒かかる場合、それは大ヒットです。しかし、私が奇妙なことをしていて、これが 1 回限りの初期セットアップ コストである場合、パフォーマンスが DB でストアド プロシージャを実行するのと同じくらい優れていれば、それだけの価値があるかもしれません。

まだ提案を受け付けています！

更新しました。

ORM/NHibernate ルートを廃棄しています。パフォーマンスが遅すぎて、使用を正当化できないことがわかりました。基本的な顧客クエリは、私たちの環境では時間がかかりすぎます。1 秒未満の応答に比べて 3 秒は多すぎます。

遅いクエリが必要な場合は、現在の実装を維持します。それを書き直すという考えは、時間を大幅に増やすことでした。

しかし、先週 NHibernate で遊んだ後では、それは素晴らしいツールです! このプロジェクトの私のニーズにはまったく合いません。

私の現在のアプリケーションは、インスタンスベースのデータアクセス層を使用しています。接続文字列を使用してレイヤーをインスタンス化します。次に、ある種のコマンドを実行するメソッドを呼び出します。たとえば、データセットを埋めるメソッドがあります。基本的に、ストアドプロシージャとSQLパラメータを渡して、データセットを取得します。データアクセスまたはインスタンスベースを処理するための静的クラスがある方が良いですか？私はオブジェクトを含むドメインレイヤーを持っていますが、ORMのようにオブジェクトをマッピングしていません。オブジェクトをファクトリに渡し、ファクトリがデータレイヤーをインスタンス化してデータセットをプルバックします。次に、データセットをオブジェクトにマップします。アプリを更新する予定ですが（もちろんC＃に移行する予定です）、全体を変更する時間がありません。挿入の更新と削除についても同じことを行います。今のところ大丈夫なら教えてください。このアプローチに問題はありますか？そうでなければ、私は何をすべきですか？私はこのクラスを書きませんでした。私はそれをオンラインで見つけ、これが私が必要としているものだと思いました。

データクラスの例を次に示します。

実際には何が良いですか？インスタンスのネストされたオブジェクトのロードを担当する複雑なクエリを持つクラスがありますか? または、単純なオブジェクトをロードする責任を負う単純なクエリを持つクラスですか?

複雑なクエリでは、データベースにアクセスする必要はありませんが、クラスの責任は大きくなります。

または、データベースにさらにアクセスする必要がある単純なクエリ。ただし、この場合、各クラスは 1 つのタイプのオブジェクトをロードする責任があります。

私がいる状況では、ロードされたオブジェクトが Flex アプリケーション (DTO) に送信されます。