1

私は悪いコードを書くという私の古い習慣のいくつかを打破しようとしています. そのうちの 1 つは、検証コードを配置する場所です。検証はプレゼンテーション層にあるべきではないと思います。または、そこにいくつかの検証がある可能性がありますか？

これは私が以前に行ったことの例です

protected void SaveBtn_Click(object sender, EventArgs e)
{

  Item itm = new Item();
  itm.Name = txtName.Text;

  if(String.IsNullOrEmpty(itm.Name))
  {
     //reject
  }
  else
  {
     ItemBLL.Save(itm); //no more validation here
  }
}

また

public class ItemBLL
{

   public static int Save(Item itm)
   {
      //no more validation in .aspx.vb
      if(String.IsNullOrEmpty(itm.Name))
      {
        //reject
      }
      else
      {
       //Save item
      }
   }
}

私は最初のアプローチを使用しており、2番目のアプローチに切り替えることを考えていますが、問題が何であるか、または一方が他方よりも優れていることを予測できません。より良いアプローチのためにもアドバイスをいただければ幸いです

更新: ユーザーのために、単純な検証 (よくある間違いなど) をプレゼンテーション (.aspx) で (javascript、jQuery を使用して) 行うことに同意します。

一部のビジネス ロジックの検証は、移植性と再利用性のために BLL にも存在する必要があります。

これは分離コード (.aspx.vb または .aspx.cs) で検証をスキップできるということですか?

4

2 に答える 2

5

どちらも最適ですが、BLL は必須です。現在、ビジネス クラスはブラウザという 1 つのインターフェイスだけで使用されていますが、明日には Web サービスでもそのクラスを使用する必要があるかもしれません。次に、すべてのビジネス ルールを Web ページではなく、クラスに含める必要があります。しかし、レスポンシブなインターフェースを提供するために Javascript でクライアント側をテストしたい多くのルールがあります。名前を空にできない例は、Javascriptでテストするための古典であり、名前に値が入るまで「保存」ボタンを有効にできません。ただし、名前フィールドは一意である必要があるとしましょう。これは、クライアント側で検証する必要がなく、サーバーに到達するまで待機したい場合があります。

于 2012-06-25T10:30:46.360 に答える
2

「検証」の意味によって異なります-特に、サーバーへの往復ポストバックの待機時間を節約する場合は、プレゼンテーション層で単純なデータ検証を行うことは完全に正当です (そして、IMO が望ましい)。たとえば、jQuery の Unobtrusive Validation ライブラリの重要なポイントは、たとえば、有効でないことがわかっているデータ (空の必須フィールド、数字のみが有効な文字など) をユーザーが送信できないようにすることです。

また、検証に対して一種の「チェックポイント」の考え方を持つことはそれほど悪い考えではないと言います。レイヤー間の境界を越えると (特に、任意の時点で異なるデータ クラスにマッピングしている場合)、そのレイヤーが意図していることに対して、データがコーシャであることを確認してください。

各レイヤーを何らかの方法で検証する利点の 1 つは、そのレイヤーをどこかで再利用する場合、新しいプロジェクトで再度実装する必要がなく、検証ロジックがそれに付随することです。

もちろん、これは私の意見です（私の経験から）。経験豊富な開発者の意見を聞きたい...

于 2012-06-25T10:30:44.410 に答える