1

クレーム管理ウィザードを備えたMVCWebアプリがあります（通常の注文入力に似ています）。クレームには複数のアイテムを含めることができ、各アイテムにはそれに関連する複数のファイルを含めることができます。

クレーム->アイテム->ファイル

新しいクレームを追加する際に、ユーザーが1つ以上のアイテムを追加できるようにし、それらのアイテムのファイルのアップロードも許可したいと考えています。ただし、クレームが実際に保存されるまですべてをメモリに保持する必要があります。これにより、ユーザーがクレームエントリを完了しないか破棄した場合でも、データベースとのやり取りは行われません。

セッションを介してデータレベルのメモリ内管理を処理できます。セッションでClaimオブジェクト（Claim.Itemsプロパティも含む）をシリアル化します。しかし、ファイルを管理する方法は？

<ClaimID> \ <ItemID>フォルダーにファイルを保存しますが、新しいクレームをメモリに作成している間、レコードがデータベースに保存されるまでIDはありません（どちらも自動インクリメントintです）。

今のところ、クレームが保存されるまで、ユーザーがファイルをアップロードすることを制限する必要があります。

4

1 に答える 1

1

データベースと対話してみませんか？アプリケーションへの複数のリクエスト間でデータを永続化することを意図しているようですが、データベースはそのために適しています。

より長期的に永続化されたデータと同じテーブルまたは同じデータベースインスタンスに永続化する必要はありません。たぶん、「一時的な」データ、または特定の状態に達するまで長期間持続することを意図していないデータ用のテーブルまたはデータベースを作成します。または、長期データと同じテーブルに保存しますが、それ以外の場合は状態を追跡して、「不完全」またはその他の方法で一時的なものとしてマークします。

古いデータを時々クリーンアップするオフラインプロセスを持つことができます。長期データテーブルで削除にコストがかかる場合は、一時データを独自のテーブルに移動するのに十分な理由があります。これは、時間の経過に伴う大量の書き込み/削除と大量の読み取りに最適化されています。

または、メモリ内オブジェクトの一時IDを使用して、データベースに永続化する前に、それらをディスク上のファイルに関連付けることもできます。おそらく、ファイル関連IDをレコードのプライマリIDから分離することさえできます。（主キーに自動インクリメント整数を使用していると想定しています。これは、データベースから取得する必要のあるIDです。）

たとえば、レコードをディスク上のファイルにリンクする目的で、 Guid（ SQLでは）である別の識別子をレコードに含めることができます。uniqueidentifierこれにより、IDを生成するために最初にデータベースと対話する必要なしに、メモリ内に識別子を作成してデータベースに永続化できます。これには、キーをいじることなく、必要に応じて別のファイルに再関連付けしたり、その識別子を変更したりできるという追加の利点もあります。

多くの場合、 AGuidを主キーとして使用するべきではないため、おそらくそのルートに行きたくないでしょう。ただし、別のIDを使用するとうまくいく可能性があります。

于 2012-09-10T13:16:47.403 に答える