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
      }
   }
}

我一直在使用第一种方法，我正在考虑改用第二种方法，但我无法预料问题会是什么，也无法预料其中一种方法的优势。请提出建议，即使是更好的方法

更新： 我同意为了用户的简单验证（例如常见错误）应该在演示文稿（.aspx）中完成（使用javascript，jQuery）。

一些业务逻辑验证也应该驻留在 BLL 中以实现可移植性和可重用性。

这是否意味着我们可以跳过代码隐藏（.aspx.vb 或 .aspx.cs）中的验证？

4

2 回答 2

5

两者都是最好的，但 BLL 是必须的。今天，您的业务类仅由一个界面使用 - 浏览器，但明天您可能希望 Web 服务也使用该类。然后，您将需要所有业务规则都在课堂上，而不是网页中。但是您需要在 Javascript 中测试客户端以提供响应式界面的许多规则。您给出的名称不能为空的示例是 Javascript 测试的经典示例，并且在名称具有值之前不允许启用“保存”按钮。但是，假设 Name 字段必须是唯一的 - 这可能不是您想要在客户端验证的内容，并且愿意等到它到达服务器。

于 2012-06-25T10:30:46.360 回答
2

取决于您所说的“验证”的含义-在表示层中进行简单的数据验证是完全合法的（并且更可取的是，IMO），特别是如果它可以节省往返回发到服务器的等待时间。这就是 jQuery 中 Unobtrusive Validation 库的全部要点，例如 - 防止用户提交我们知道无效的数据（空的必填字段、只有数字有效的字母等）。

我还要说，对验证有一种“检查点”的心态并不是一个坏主意：一旦你跨越了层之间的边界（特别是如果你在任何时候映射到不同的数据类），让确保数据对于该层打算用它做什么是洁净的。

以某种方式验证每一层的一个优点是，如果您在某处再次重用该层，验证逻辑就会随之而来，而不需要在新项目中再次重新实现。

当然，这只是我的意见（根据我的经验）。我想听听更有经验的开发者怎么说...

于 2012-06-25T10:30:44.410 回答