問題タブ [data-access-layer]

DTOを使用してオブジェクトリレーショナルレイヤーとデータアクセスレイヤーの間でデータを転送することは理にかなっていますか？このパターンはいつ有用で、いつアンチパターンになるのでしょうか。

数年ぶりに .NET 開発に戻ってきましたが、特に LINQ を使用すると、データへのアクセス方法が変わり、はるかに簡単になったようです。たとえば、ASP.NET MVC Web サイトでは、次のことができます。

• アイテムを追加
• LINQ-to-SQL クラスを追加する
• データベース テーブルを LINQ-to-SQL オブジェクト リレーショナル デザイナーにドラッグし、[保存] をクリックします。
• LINQワンライナーを介してデータにアクセスして操作します（ここで学びました：http://www.asp.net/learn/mvc/tutorial-11-cs.aspx）

これは素晴らしいように見えますが、実際にはどのように機能しますか?

• 上記の LINQ-to-SQL シナリオは実際のプロジェクトで使用するものですか、それとも簡単なスキャフォールディング テクノロジですか。つまり、データベースでフィールドとテーブルの追加、削除を開始するとどうなるか、LINQ-to-SQL クラスはどのように機能しますか同期を維持しますか？

そして、この分野のすべての新しいテクノロジーをどのように理解すればよいでしょうか。

• サブソニックはどこに収まりますか?
• Astoria (ADO.NET Data Services) はどこに適合しますか?
• NHibernate はどこに適合しますか?
• LINQ-to-SQL で他のデータベースを使用するにはどうすればよいですか (オブジェクト リレーショナル デザイナーで SQLite テーブルをドラッグしようとしたところ、「サポートされていません」というエラーが表示されました)、または LINQ-to-SQL は SQL Server 専用ですか?
• LINQ-to-XML は LINQ-to-SQL と同じように機能しますか? たとえば、XML ファイルをデザイナーにドラッグして LINQ でアクセスできますか? それとも、独自のコードを記述する必要がありますか?

• LINQ-to-Entities は LINQ-to-SQL のように機能しますか。つまり、自動的に生成されたクラスですが、より多くのオプションがありますか?

• ADO.NET とその DataTables および DataSets は、LINQ がある今では古いテクノロジですか? LINQ-to-ADO.NET は理にかなっていますか?

• Azure は、もはや RDBMS を実際に持っていない場所のどこに適合しますか?

• UI がただ RESTful に WCF と話している、または Web サービスと話しているだけの場合、ESB はどこに収まるのでしょうか?

非常に多くのオプションが用意されていますが、プロジェクトにこれらのテクノロジのいずれかを選択できるとしたら、どれを選択しますか?またその理由は何ですか?

.NET DAL クラスの単体テストに満足できるオプションを探しています。これらは DAL クラスであるため、ADO.NET を使用してデータベースに直接アクセスします。現在、テストに MSSQL データベースのインスタンスを使用していますが、より高速なオプションがあるかどうか疑問に思っていました.--単体テストはできるだけ速く実行する必要があるため、インメモリ ソリューションが理想的です。

また、私は Microsoft プラットフォームしか使用しないため、TSQL に縛られていることも言及しておく必要があります。

私はデータアクセス層を書いています。システム内の接続の管理について混乱しています。.net が接続プールを使用していることは知っています。しかし、すべての dml 操作またはすべての SQL クエリでデータベース接続を開いたり閉じたりしたくありません。どうすればこれを処理できますか? どこで、いつ (データ アクセス レイヤーを使用するグローバル asax またはデータ アクセス レイヤーで) 接続を管理する必要がありますか?

私は (Spring MVC フレームワークを使用して) MVC Web アプリケーションを構築していますが、特定の領域を設計する最善の方法に少し困惑しています。

アプリケーションは一連の Web サービスとやり取りする必要がありますが、これらの Web サービスはそれほど大きく設計されておらず、それ自体であまり抽象化されていません。基本的に、作成/更新/取得/削除操作ごとに Web サービス メソッドがあります。それぞれの「データ型」であり、それ以上の API はあまりありません。Web サービス クライアントは、必要なデータを作成するために、どのメソッドをどの順序で呼び出すかを知る必要があります。つまり、「トランザクション」ベースのメソッドはありません。

たとえば、単純に新しいユーザー アカウントを作成するには、合計 7 つの異なる Web サービス メソッドを呼び出して、必要なテーブルのすべてのレコードをセットアップする必要があります (userレコード、そのユーザーへの正しいレコードの追加、privilegesユーザーの詳細のセットアップbillingなど)。 .

これを抽象化し、アプリケーション内にカプセル化する最善の方法に苦労しています。アプリのほとんどは、標準的なフローに従います。

アプリケーション内で、独自の「ドメイン オブジェクト」のセットを使用して、Web サービス WSDL で定義されたデータ型を表現および抽象化しているため、ドメイン ロジックは Web サービスの型に依存せず、抽象化および非表示にできます。私たちが好きな詳細。

私が意見を求めているのは、例として上で述べた「ユーザー作成プロセス」を設計するための最良の方法です。「通常のユーザー」を作成するプロセスには、前述のように 7 つの異なる Web サービスを呼び出すことが含まれますが、これはユーザーの「タイプ」の 1 つにすぎません。いくつかの異なるタイプのユーザーを作成できる必要があり、それぞれに異なる必要があります。呼び出される Web サービス。

現在、私はこの「通常のユーザー」の作成のみを、少しの概念実証としてUser設計UserDaoしました。 7 つの Web サービス メソッドについて言及しました。メソッドは によって呼び出されます。これは私のビジネス/サービスレベル クラスであり、 によって呼び出されます。getUser(name)createUser(User)WebServiceUserDaoUserDaocreateUser()UserCreationServiceSignupController

しかし、このロジックを拡張してさまざまなユーザー タイプを作成できるようにするには ( User.getType(). :

1. 「ユーザー タイプ」ごとに1 つのUserDao実装を作成して、各「ユーザー タイプ」を作成するロジックを独自のクラスにカプセル化して、UserCreationServiceどちらUserDaoを使用するかを決定できるようにします。これは、1 つのサービス クラス: 多くの DAO に対応します。
2. UserDaoアプリケーション全体がこれらの個々のタイプのそれぞれについて知る必要はありませんが、Web サービス/DB で作成する必要がある各「レコード」に対応する小さな部分に分割する必要がありますか? そしてUserCreationService、さまざまな異なる「ユーザータイプ」に対して異なる実装がありますか? つまり、対応するオブジェクトやドメイン オブジェクトが必要ない場合でも、この戦略には a PrivilegesDao、 aなどがあります。これは、多くのサービス クラス: 多くの DAO になります。BillingPlanDaoPrivilegeBillingPlan
3. 「ユーザー タイプ」ごとに Web サービスを呼び出す必要があるすべてのロジックを単一のWebServiceUserDao? これには、非常に複雑なクラスを持つという欠点があります (そして、PMD は循環的複雑性についてすでに不満を持っています) が、このロジックはすべて 1 つのクラスにカプセル化され、API 全体の観点から見ると複雑さが軽減される可能性があります。

このアプリケーションでの目標の 1 つは、データの永続性の詳細を変更する必要がある場合に、DAO の実装を変更するだけで済むようにすることです。別の課金システムとのインターフェイスを開始する必要がある場合は、アプリケーションのどの部分も、DAO レベル以外で変更したくありません。

ご意見はありますか？「ビジネス ロジック」と「データ アクセス ロジック」が重複しているように見える場合、どこを分割するかを決定する際に、どのような戦略を使用しますか?

データベース内の 1 つのテーブルで表される Person、Campaign、Event などの基本的なドメイン オブジェクトがあります。ただし、PersonCampaign や PersonEvent、さらには基本オブジェクトの 1 つを理論的に拡張できる CampaignEvent など、これらのオブジェクトのより複雑なバージョンもあります。

ただし、PHP は多重継承をサポートしていないため (たとえば、PersonEvent は Person または Event を拡張します)、これは複雑になります。また、一部のドメイン オブジェクトは、実際にはさまざまなプロパティと機能を持つファクトリ オブジェクトです (たとえば、Event は実際には、電子メール、通話、FAX などのイベントの種類によってサブクラス化されます)。

私が見ることができる最も簡単な解決策は、データ アクセス層から返されるデータに基づいて、オブジェクトの実際の性質を変更することです。

これを処理するためのより良い方法について何か提案はありますか? それとも、データ アクセス レイヤーから現在利用できるものに基づいて、プロパティと動作を変更できる統合ドメイン オブジェクトを作成するのが正しいのでしょうか?

.Net O/R (オブジェクト/リレーショナル) マッパーはすぐに非同期メソッドを提供しますか?

できれば非同期メソッドのボイラープレートを書きたくない

CCR フレームワークを使用して、非同期メソッドで独自の DAL を作成しました。CCR は基本的に、IO 応答を待っているスレッドをブロックしないことを要求します。

これまでのところ、私のソリューションの良い点は、それが最小限に抑えられていることです。しかし、このプロジェクトが規模と機能の面で成長するにつれて、生の SQL クエリとボイラー プレート コードを維持するという、やや困難なタスクに直面しています。

しかし、一方で、O/R マッパーの非同期メソッドが実際には複雑さの奇妙さを追加する厄介なハックである場合、私は良くありません。

非同期プログラミングに代わるものに注目しないでください。