1

データベースに存在するユーザーインターフェイスからレコードを削除する際に、一般的に参照される方法論やデザインパターンやモデルのようなものはありますか?

基本的に、次のどのような手順をいつ実行する必要がありますか (検証、メイン レコードの削除、エラーが発生した場合の処理​​方法など)。

REFERENCE 制約との競合

例外を処理する方法、または失敗をユーザーに通知する方法 (BL 失敗情報を UI に転送する方法、例外やレポート オブジェクトなどをキャッチする方法) と、削除コンテキストに関する多かれ少なかれ最も一般的な問題。

4

4 に答える 4

1
  1. Web UI のリンクを削除すると、「ページの削除」が開きます。
  2. GET の「ページの削除」では、関連レコードの存在などの前提条件を検証する必要があります。検証が失敗した場合、フォームを表示しません。
  3. 「削除ページ」への POST は、前提条件を再度検証し、1 つのデータベース トランザクションでデータベース レコードを削除する必要があります。
  4. 2 番目の検証が失敗した場合、またはデータベース例外が発生した場合は、一般的なエラー メッセージが表示されます。
于 2011-04-11T14:31:20.377 に答える
0

レコードを削除すると、いくつかのことができます。

  1. 項目がデータベース内でまだ同期しているかどうかを確認してください。(このステップは、シナリオによってはオプションになる場合があります)
  2. 削除を実行します。
  3. 削除が成功した場合は、GUI を更新します。失敗した場合は、例外をキャッチし、GUI を更新/変更しません。

ビジネス層に何を使用していますか? また、データを取得してコードに保存するためにどの API を使用していますか?

于 2011-04-11T14:30:23.277 に答える
0

あなたが説明したようなデータベースの問題については、集中型の例外管理戦略を検討して、例外がデータ層で一貫してキャッチされ、スローされるようにします。あなたがすべき：

  • データ アクセス レイヤーでキャッチして処理する必要がある例外を特定します (例: デッドロック、接続の問題は DAL 内で解決できます)。
  • ただし、制約違反などの言及した例外は、解決のためにユーザーに提示する必要があります
  • 特定の例外 (基本の Exception クラスではない) が検出された場合は、データ レイヤーまたはサービスを呼び出しているビジネス レイヤーにこれをバブル アップさせます。ビジネス層は、発生した例外を収集し、UI で適切に処理できるカスタム例外をスローできます。
于 2011-04-11T14:51:55.707 に答える
0

まず最初に、DataLayer を実際のバックエンド データ ストアから分離する必要があると思います。Hibernate または Microsoft の Entity Framework を使用して、ORM (オブジェクト リレーショナル マッピング) を簡単にすることができます。GUIで表示するデータが、DB内のデータを表すオブジェクトを表すようにします。

MS Entreprise Libraries Validation ブロックを検証に使用できます。

また、Winforms または WPF を使用しているかどうかによっても異なります。単体テストで更新ビットをテストできるように、ある種のサービス/モデルがGUIではなくすべてのCRUD操作を処理していることを確認する必要があります

于 2011-04-11T14:31:05.490 に答える