3

私たちは、C# 4 と SQL Server 2008 R2 を使用して、ドメイン駆動型の設計原則に従ってシステムを開発しています。ORM は使用されません。次のような別のエンティティのコレクションを保持するエンティティがある状況があります。

public class Project
{
    public IdCollection ParticipantUsers
    {
        get
        {
            //...
        }
    }

    public void AddParticipantUser(Id idUser)
    {
        //...
    }

    public void RemoveParticipantUser(Id idUser)
    {
        //...
    }
}

のParticipantUsersプロパティはProject、それに参加しているユーザーの ID のコレクションを返します。AddParticipantUserおよびメソッドはRemoveParticipantUser、わかります。

見つかった問題は次のとおりです。プロジェクト インスタンスがリポジトリに送信されてデータベース上で更新されると、ParticipantUsersID のコレクションが最後に取得されたときから変更されている可能性があります。一部の ID は追加され、一部は削除され、一部は正確に変更されている可能性があります。同じ。力ずくのアプローチを使用して、このプロジェクトのすべての参加ユーザーをデータベースから削除してから、現在のユーザーを再挿入することができますが、より良いアプローチを検討したいと思います。

追加された ID のみを挿入し、削除された ID を削除し、コレクションにまだ残っている ID をそのままにしておくことができる、より良いアプローチを考えてみてください。

4

5 に答える 5

2

この種のことを多く行う場合は、イベント ソーシングが理想的だと思いますが、通常、開発者として、新しい手法をあまり使用することはありません :)

私は ORM のファンではないので、以前に行ったことは、作業単位が行うのと同じ行に沿って変更のリストを保持することだけでした。したがって、参加者が追加されるたびにAddedParticipantsコレクションに追加し、削除された参加者についてはRemovedParticipantsコレクションに追加します。各エントリの変更の種類を含む単一のリストにさらに進むことができると思います。しかし、私はあなたがその考えを理解すると確信しています。

リポジトリは、追跡された変更を使用して、関連するデータ操作を実行します。最も美しい解決策ではないかもしれませんが、それは仕事を成し遂げます.

短いリストの場合は、単純に削除して再挿入することを追加するかもしれませんが、あなたが述べたように、このシナリオではやや重くなる可能性があり、1つのサイズがすべてに適合するわけではありません:)

もちろん、Arie が提案したように、リストをリロードして比較することは問題なく機能します。

于 2013-07-10T16:39:04.237 に答える
2

実際には、削除と再挿入のアプローチは、比較に基づくどのソリューションよりも優れていると思います。

まず、実装が簡単です。

第 2 に、比較のために別のデータを取得する必要がありません。

このアプローチが好まれない理由についてさらに説明していただけますか。おそらく私はそれを理解していません。

于 2013-07-10T14:25:26.843 に答える
1

すべての ID を 1 つの列にシリアル化することを検討しましたか? このように、1 つのレコードを更新するだけです。その間にコレクションが変更されたことが心配な場合は、オプティミスティック コンカレンシーを実装することをお勧めします。

于 2013-07-11T01:44:54.643 に答える