0

私のアプリでは、一連の検証クラスを作成して、たとえば、ユーザーが入力したクラスの Name プロパティ (WinForm から) がデータベース内の varchar() のサイズを超えていないことを確認しています。

現在、名前フィールドが大きすぎる場合、検証コードはカスタム例外をスローします。(カスタム例外は、UI によってキャッチされると、通常の例外の一般的なエラー フォームとは対照的に、MessageBox にカスタム例外メッセージを表示します。) 検証クラスはアプリのクラス ライブラリにあり、Friend としてスコープされます。フローは次のようになります。

  • WinForms によって使用される DLL のパブリック サービス レイヤー --(calls) --> Friend Validation Layer
  • WinForms によって使用される DLL のパブリック サービス レイヤー --(calls) --> 検証が成功した場合のフレンド データ アクセス レイヤー。

簡単な例:

Public Shared Sub CreateCustomer(cust as Customer)
    Validation.Customer.ValidateForCreate(cust) ' scoped as Friend
    Dal.Customer.Create(cust) ' scoped as Friend
End Sub

検証が失敗したときに検証レイヤーがカスタム例外を UI にスローするのは「スマートな」設計ですか?

Validation Layer から True/False を返すだけで、何が失敗したかを示す文字列メッセージを返し、Service Layer でスローされた例外を処理する方が良い設計ですか?

Validation Layer から True/False を返すだけで、Services Layer が True/False を UI にバブルアップさせ、何が失敗したかの文字列メッセージを表示する方が良い設計ですか?

オブジェクト指向のアプローチを維持しようとしています。私の意見では、カスタム例外をスローしても OOP の原則が破られることはありませんが、他の意見が欲しいです :)

4

1 に答える 1