1

みなさん、こんにちは。

c＃.net VS 2008では、N層CRMフレームワークソリューションを開発しており、それが完了したら、それを共有したいと思います。

アーキテクチャは以下に基づいています。

データアクセス層、エンティティフレームワーク、Bussinesロジック層、WCF、そして最後にプレゼンテーション層（Winフォーム）。

どこかで読んだところによると、オプティミスティック同時実行更新（同じデータを使用する複数のクライアントトランザクション）が原因で、2層を超えるレイヤーには問題があります。

最大で 2層レイヤーソリューションこれは、この問題を自分で解決するコントロール（datagridviewなど）があるため、問題にはならないはずです。したがって、2層レイヤーで作業する方がよいのではないかと自問し、楽観的同時実行性を回避します。問題？

実際、私は2層ではなく、巨大なプロジェクト向けのN層層ソリューションを作りたいと思っています。このような並行性の問題を解決する方法がわからないので、ここで助けを求めています。

確かに、これを解決するためのいくつかの良いメカニズムがあるはずです...多分何か提案、例など？

期待していただきありがとうございます。

よろしく、Jooj

4

3 に答える 3

3

これは層の数の問題ではありません。問題は、データ アクセス ロジックが同時実行をどのように処理するかです。同時実行の処理は、層の数に関係なく、データ アクセスを処理する層で行う必要があります。しかし、.NET コントロールとコンポーネントはこの機能を隠し、必要な層の数を減らすことができるので、あなたがどこから来ているのか理解しています.

オプティミスティック コンカレンシー解決には、2 つの一般的な方法があります。

1 つ目は、行のタイムスタンプを使用して、ユーザーが編集を開始したときに表示していたバージョンが、編集をコミットするまでに変更されているかどうかを判断することです。これは必ずしも適切な Timestamp データベースのデータ型ではないことに注意してください。システムが異なれば、それぞれ独自の利点と欠点を持つ異なるデータ型が使用されます。これはより単純なアプローチであり、適切に設計されたほとんどのデータベースでうまく機能します。

2 番目の一般的な方法は、変更をコミットするときに、id だけでなく、ユーザーが変更したフィールドのすべての元の値によって問題の行を識別することです。フィールドの元の値と id が編集中のレコードで一致しない場合、それらのフィールドの少なくとも 1 つが別のユーザーによって変更されていることがわかります。このオプションには、2 人のユーザーが同じレコードを編集しても、同じフィールドを変更しない限り、コミットが機能するという利点があります。欠点は、ビジネス ルールに関する限り、データベース レコード内のデータが一貫した状態であることを保証するために余分な作業が必要になる可能性があることです。

ここでは、EF で単純な楽観的同時実行を実装する方法についての適切な説明を示します。

于 2010-10-12T13:51:32.837 に答える
1

手動マージ (変更セットと衝突の決定) を組み合わせて使用​​し、データ要件に応じて最後の人が勝ちます。データの変更が共通の元の値から変更された同じフィールドに衝突すると、マージ タイプの例外がスローされ、クライアントがそれを処理します。

于 2010-10-12T11:53:10.643 に答える
1

いくつかのことが頭に浮かびます：

1) EF を確実に使用している場合は、データ アクセス レイヤーがありませんか?! データベース自体のことですか？

2) 階層を伴う質問は、物理的かつ論理的なものです。では、物理的または論理的という意味ですか?

3) 任意の層のアプリケーションでは、同時実行性にこの問題があります。クライアント/サーバーでさえ、人々はフォームを開き、どこかに行って戻ってきて、他の誰かによってデータが変更されている間に保存することができました. タイムスタンプを使用して保存中に確認し、最後の更新がデータを取得したときであることを確認できます。

4) 階層の増減についてあまり考えないでください。機能をできるだけシンプルに、最小限のレイヤー数で実装するだけです。

于 2010-10-12T11:58:42.423 に答える