問題タブ [change-tracking]

INotifyPropertyChanged はかなり自明であり、いつそれを上げるべきか (つまり、値の更新が完了したとき) は明確だと思います。
INotifyPropertyChanging を実装すると、オブジェクトの状態を変更するセッターまたはその他のメソッドに入るとすぐにイベントが発生し、発生する可能性のあるガードと検証を続行する傾向があります。

そのため、プロパティが変更される可能性があるが、まだ変更されておらず、実際には変更が正常に完了していない可能性があるという通知としてイベントを扱っています。

オブジェクトのコンシューマーがこのプロパティを使用している場合 (変更追跡のためにイベントを使用する LINQ to SQL のように)、与えられた値が適切であり、オブジェクトの状態は変更に対して有効ですか?

このイベントのコントラクトは何ですか? サブスクライバーにはどのような副作用がありますか?

私の経験から、.NET の主要な ORM フレームワーク ( NHibernate、LinqToSql、Entity Framework ) は、読み込まれたオブジェクトを追跡するときに最適に機能します。これは単純なクライアント/サーバー アプリケーションでは問題なく機能しますが、サービス指向アーキテクチャで Web サービスを含む 3 層以上のアーキテクチャを使用する場合、これは不可能です。最終的には、自分で追跡を行うコードをたくさん書くことで実現できますが、ORM は DB アクセスを簡素化するためのものではないでしょうか。

サービス指向アーキテクチャで ORM を使用するという考えは、まったく良いのでしょうか?

複数のユーザーが同時に変更、削除、追加できるエンティティのリスト (TODO アイテムのリストなど) があるとします。

したがって、すべてのクライアント間で同期されたリストを維持するには、各クライアント (AJAX ベース) が xx 秒ごとに変更を要求するようにします。リストは非常に長くなる可能性があるため、毎回完全なリクエストを行うのではなく、変更された項目のみを要求します (項目は更新、削除、または新規作成できます)。

ADO.NET Data Services で可能ですか? その場合、サーバーで Entity Framework を使用している場合、どのように実装すればよいですか?

変更操作がデータ サービスに送信されたときに変更項目を格納するために ASP.NETs キャッシュを使用することを検討し、特定のクライアントの最後の要求以降の最新の変更を返すカスタム Web メソッドを用意しました (要求はクライアントを通じて追跡できます)。 ASP.NETs セッション オブジェクト)。ただし、結果セット内の個々のアイテムの変更状態 (削除、更新、挿入など) を示す方法がわかりません。

優れたソリューションは、クライアントがサーバーへの同じラウンドトリップで多くのエンティティの変更を要求できるようにもします。

どんな入力でも大歓迎です。

よろしく、エギル。

MySQL データベースの変更を追跡するためにどのツールを使用していますか?
現在、私は、データベースに変更を加えるときに SQL ステートメントを手動で追加するプレーン テキスト ファイル (SVN を介して管理されるバージョン) を使用するプロジェクトに参加しています。
変更の多くは時々魔法のように消えてしまいます。現在、データベースを変更追跡するためのより良い方法を探しています。

編集：
私が言及するのを忘れたことの1つは、ストアドプロシージャと関数を使用しているため、/バージョン管理の変更を追跡したいのはデータベース構造だけではありません。

ビジネスエンティティの更新を永続化する前に、検証チェックを実行して、変更されたプロパティを特定する必要があります。たとえば、特定のフィールドは、「ステータス」プロパティに特定の値がある場合にのみ更新できます。たとえば、注文エンティティのステータスが確定済みの場合、更新できるのはメモ（文字列）フィールドのみです。NHibernateを使用してこの種のことは可能ですか、それともビジネスエンティティの変更を自分で追跡する必要がありますか？

MSDN にこれに関するドキュメントがないため、ここで質問せざるを得ません。

Express バージョンは、他のエディションと同じ変更追跡機能をサポートしていますか?

ありがとう

レピー

ADO.NET Framework モデルとその関係に加えられたすべての変更を拒否する方法があるかどうかを尋ねたかっただけです。 Entity Framework での監査では、単一のエンティティの元の値を復元する方法について説明しています。しかし、これはデータベース全体のすべての保存されていない変更に対して可能ですか?

私のアプリケーションでは、フィールド レベルの変更追跡を行う必要があるいくつかの異なる種類のエンティティがあります。私はこれをグーグルで検索しましたが、すでに永続化されているエンティティのフィールドを変更するだけで、単純な「挿入日」および「更新日」監査追跡を行う例しか思いつきません。次の理由により、私の要件はより複雑です。

1. 保存されているエンティティのフィールドを変更するだけでなく、変更を表す新しいエンティティを作成する必要があります (私が見つけた挿入日、更新日の例のように)
2. 追跡されたエンティティを更新する同じトランザクションで、これらの新しいエンティティを DB に保存する必要があります
3. 追跡対象のエンティティに添付された ValueObjects のコレクションへの変更を追跡する必要があります
4. 追跡対象のエンティティごとに個別のログ コードを記述する必要はありません。

コード例:

Account オブジェクトまたは Computer オブジェクトのいずれかの値が変更されるか、Computer オブジェクトに関連付けられた IPAddresses のリストが変更されるたびに、次のエンティティ変更レコードを作成して保存する必要があります。

追跡対象の各エンティティは ITrackChanges マーカー インターフェイスを実装し、各値オブジェクトは ValueObject 基本クラスから継承します。値オブジェクトは、NHibernate のコンポーネントとしてマップされます。

最終結果として取得しようとしているものの例として、Computer オブジェクトを ID 1 で更新し、AssetTag を "ABC123" から "ABC124" に変更し、IP アドレスのリストを { "1.2.3.4" から変更するとします。 " } を { "1.2.3.4" , "1.2.3.5" } に変更すると、2 つの EntityChange レコードを取得する必要があります。

これを実装するための最良の方法に関するアイデアはありますか? ドキュメントを読んだところ、インターセプターやイベントリスナーを作成する必要があるように見えますが、更新中のエンティティを変更するだけの例を見つけることができませんでした。サンプルコードは、どんな回答でも大歓迎です。

これが NHibernate でサポートされているものであると仮定するのは間違っていますか? ORM として LLBLGen を使用する以前のアプリケーションでこれを実装できましたが、NHibernate を使用するアプリケーションでこれを実装しなければならなかったのはこれが初めてです。

次のフィールドを持つusersテーブルがあります: userid, phone, and address. これはユーザーデータなので、ユーザーがいつでも変更できるようにしています。問題は、これらの変更を追跡し、古いデータも保持したいということです。私が検討したアイデアのいくつかを次に示します。

• 新しいデータを古いデータに追加し、パイプのようなセパレーターを使用します。フィールドを取得するときに、そのセパレーターの存在を確認し、存在する場合は、その後の文字を新しいデータとして取得します。(面倒だし気持ち悪い)

• changes次のフィールドを持つ別のテーブルを設定します: userid, fieldname, fieldcontent. ユーザーがデータ (任意のデータ) を変更した場合、ユーザーのユーザー ID、フィールドの名前/ID、およびフィールドの古いコンテンツの下にあるこの別のテーブルにイベントを記録し、古いデータを上書きできるようになりました。users新しいものと一緒に。このユーザーが行ったすべての変更を見つけたい場合は、ユーザーchangesID でテーブルを検索します。これに関する問題は、(すべてのフィールドの) すべてのデータ変更を 1 つのテーブルに混在させているため、さまざまなフィールド タイプに対応するためにfieldcontentフィールドをchangesテキストにする必要があることです。これはまだ最初のアイデアよりも優れているように見えますが、正しいことをしているかどうかはまだわかりません.

古いデータを保持するための他のアイデアや既知のベスト プラクティスはありますか?

前もって感謝します

アーキテクチャを結合されたものから疎結合の SOA (WCF) に移行しています。相互に通信するいくつかのサービスがあります。サービス間でビジネス インスタンスをどのように同期しますか?

ここには 2 つのシナリオがあります。

1. すべてのビジネス オブジェクトは 1 つのサービスでのみ作成されます。それをMainServiceと呼びましょう。オブジェクトに加えられたすべての変更にアクセスできる唯一のサービスです。このサービスは、データベース内のオブジェクトの更新を担当します。オブジェクトが更新されると、通知が発生します。他のサービスは、必要なイベントに登録し、それに応じて通知を受け取ります。私はこれを集中型アプローチと呼んでいます。

   + 変更が行われるとすぐにサービスに通知する
   - サービス間の呼び出しが多い。
   - より多くのカップリング。

2. すべてのサービスは、必要なオブジェクトをロードし、データベースに加えられた変更を定期的に監視します。私の考えは、SQL Server 2008 の変更追跡を使用して、オブジェクトに加えられた変更を検出することでした。

   + トラフィックが少なくなり、サービス間の通信の問題が発生する可能性があります。
   + 低結合
   - 定期的な監視による遅延。

それで、これについてあなたの答えは何ですか？（3、4等があれば・・・それもいいですね）