問題タブ [data-access]

Visual Studio 2008 を使用して .Net 2.0 アプリケーションを保守しています。アプリケーションがビルドされたとき、アプリケーションはもともと Visual Studio 2003 にあり、データ アクセスに System.ComponentModel.Component クラスを使用していました。コマンド、接続などをコンポーネントのデザイナー サーフェイスにドラッグ アンド ドロップできます。

2008 では、データ アクセス クラスはコンポーネントに「固執」しません。つまり、コマンドのコードはクラスで生成されません。

1. これはいつ変更されましたか？2005年?
2. おそらくdb proエディションを使用して、この動作に代わるものはありますか?

ありがとう。

こんにちは、少し前に質問を投稿しましたが、いくつかの異なるテクノロジを検討する必要があるという返信がありました。上記のうち、最も人気のあるもの、またはサポートされているものはどれですか (または他のことを自由に述べてください)。

以前の質問で述べたように、私は ASP.Net MVC を学んでいます。私は Java Struts のバックグラウンドを持っていますが、大多数の人々が ASP.Net MVC と組み合わせて使用​​しているものを試して学ぶ準備ができていますか?

編集：私は簡単なGoogle Trendsを試して、最も人気のあるものをピックアップしました（最も検索された=最も人気がある=最もサポートされていると仮定すると、はい、短い落ち込みに満ちた概念です）LINQが最善の方法です：

Google トレンド

次の状況を考えてみましょう

ファイル: ./include/functions/table-config.php 以下を含む:

p>

ファイル: ./include/classes/uri-resolve.php 以下を含む:

p>

ファイル: ./settings.php 以下を含む:

これは機能しますか。つまり、process_uri() からの $tablePages へのアクセスは受け入れられるのでしょうか、それとも誤った結果が得られるのでしょうか。

エラーが発生する可能性がある場合は、修正または回避策を提案してください。

最近、会社では、現在のソリューションに統合する必要のある古いプロジェクトからMSSQLデータベースを入手しました。

データベースには、FOR XML AUTO句を使用する約100〜150のストアドプロシージャがあるため、クエリは行ではなくXMLとして完全なオブジェクトグラフを返します。

（社内の）最も迅速な解決策は、データベースから返されたxmlデータに基づいて（xsd-toolを使用して）シリアル化可能なクラスを作成することでした。

これは、これらのオブジェクトをインスタンス化するために使用するコードです。

DBは、エンタープライズライブラリのデータベースクラスを表します。

spが大量のデータを返す場合（たとえば、多数の子、孫、grandgrndchldrn ...オブジェクトを含むオブジェクトの大きなコレクション）、このメソッドの実行は非常に長く続きます。

アプリケーションのデータは今後も増え続けるので、これを最適化することを考えなければなりません。

したがって、これが悪い習慣（FORXML、XmlReader、Deserializeを使用）なのか、ストアドプロシージャを書き直してSqlDataReadersまたはLinq2Sqlを使用する必要があるのか​​、またはこのスニペット内にperf.issueがあるのか​​（ジェネリックスなどの不適切な使用） ）？

---

編集 一度に大量のデータをロードするのは悪い習慣であり、ロードプロセスを小さなチャンクに分割する必要があることは知っていますが、この特定のコードに何か問題があるのではないかと思っています。

これが私の既存のコードです：

締め切りに間に合わず、汗だくです。過去数日間、私は問題に取り組んできましたが、今こそ大声で叫ぶときです。

アプリケーション (「APP」と呼びましょう) があり、APP 用に作成された「PerformanceStatistics」MBean があります。また、MBean がアプリケーションのランタイムにアクセスして計算するためのデータを提供するシングルトン データ クラス (「SDATA」と呼びましょう) もあります。したがって、アプリケーションの起動中とその後のアプリケーションのライフサイクル中に、SDATA インスタンスにデータを追加します。そのため、この SDATA インスタンスには常にデータが含まれています。

問題は、PerformanceStatistics MBean からデータまたはデータ構造にアクセスできないことです。データを追加するときにデータ構造を確認すると、すべての構造にデータが含まれています。しかし、MBean からこのシングルトン インスタンスを呼び出すと、空のデータが表示されます。

何が起こっているのか、誰かが説明したり、ヒントを得ることができますか? どんな助けでも大歓迎です。

念のため、あらゆる種類の SDATA クラスを final にして、すべてのメソッドを同期、静的などにしようとしました。しかし、今まで運がありません。

もう1つの残念なことは、異なる「ServicePerformanceData」インスタンスを取得する場合があることです（つまり、 ServicePerformanceData.getInstance() を出力すると、それらは異なる時点で異なります）。何が起こっているのかわからない。このアプリケーションを WebLogic サーバーで実行し、JConsole を使用しています。

シングル トンおよびデータ アクセス メソッドを持つ SDATA クラス

}

PerformanceStatistics MBean クラスServicePerformanceData .getInstance() のようなデータを呼び出すと、その構造には何もありません。したがって、私はこれで結果を得ることができません。

}

「昔ながらの」VB6データベース開発者である友人が何人かいて、.NETとその機能、特にADO.NETについて話していました。

私たちの会話の中で、彼らはADO.NETに移行するよりもADOに固執したいという次の理由を提起しました。

• データセットが切断されています（電源障害が発生した場合はどうなりますか？）
• 同じ量のコードを書く必要があります
• の新しいオプションDataset、BindingSourceおよびTableAdapter混乱しているようです
• 同じコードがプログラムでデータベースにアクセスするように記述されています。変更されるのは、そのコマンドのレイアウト方法だけです。

Windowsフォームアプリケーションに関して、データアクセスに関してADO.NETがADOよりも「優れている」理由や答えを探しています。ADO.NETは、ADOが提供しないものを提供しますか？ADOよりも優れている点は何ですか？

注意： LINQを含まない例が欲しいのですが。

SqlDataReader を使用して、Winform アプリにエンティティを設定しています。エンティティ クラスには、エンティティ クラスのプロパティとして設定したいデータベースにいくつかの外部キー属性があります。各プロパティは、ID および説明プロパティを持つ「属性」タイプになります。

システムの一部のユーザーはデータベースから遠く離れているため、データ アクセスのパフォーマンスは重要な考慮事項です。

単一の結果セットを返すストアド プロシージャに対して SqlCommand.ExecuteReader を複数回 (属性ごとに 1 回) 実行するか、複数の結果セットを返すストアド プロシージャに対して SqlCommand.ExecuteReader を 1 回実行し、SqlDataReader.NextResult を使用することができます。それらを移動して属性を設定します。

.NextResult でループすると、ストアド プロシージャとプロパティ割り当てのループが一致していることを確認する際に問題が発生します。proc の SELECT ステートメントの順序が変わると、winform アプリの割り当て順序がめちゃくちゃになります。

とにかく、SqlDataReader が読み取りごとにデータベースに戻る場合、SqlCommand.ExecuteReader の実行に多くの時間が追加されますか? 各属性に対して ExecuteReader を実行すると、割り当て側で物事がより明確になります。

ありがとう！

データベースファクトリの作成方法や接続プールの処理方法に関する多くの情報を見つけましたが、完全な解決策はどこにも見つかりませんでした。

私はいつも自分のソリューションを使用してきましたが、完全ではないか、改善できると思います。

私がネット上で見つけることができるあなたの誰かが使用するいくつかの良いデザインのクラスはありますか？

ありがとう ;-）

私は基本的にデータアクセスレイヤーを書くのにうんざりしています。私はそれを退屈で無意味な努力だと思っています。エンティティ/モデルを作成してアプリケーションの構築を開始できる開発環境を想定しています。DALや手順などを書くのにかかる時間は、プロジェクトに対する私の熱意を損なうだけです。

私が欲しいのは、私のデータ用の汎用リポジトリインターフェースです。何かのようなもの：

私は特に何かのために働くことに興味があります

• Azure Data Services
• SQLサーバー
• sqLite

...しかし、理論はすべてのデータリポジトリに適用されます

誰かがすぐに構築されたソリューションに出くわしたことがありますか、それとも私がこれまでに固執したかったよりも多くのデータアクセスレイヤーを書くことによって問題を修正する必要がありますか？

注：ORMについては知っていますが、DALまたはストアドプロシージャを作成する必要がないものが必要です。