asp.net-mvc - 将业务逻辑应用于 ASP.NET MVC 中的表单元素

Question

我正在寻找将业务逻辑应用于 ASP.NET MVC 应用程序中的表单元素的最佳实践。我假设这些概念适用于大多数 MVC 模式。目标是让所有业务逻辑都来自同一个地方。

我有一个包含四个元素的基本形式:
文本框:用于输入数据
复选框:供员工批准
复选框:用于客户批准
按钮:用于提交表单

文本框和两个复选框是使用 LINQ to SQL 访问的数据库中的字段。我想要做的是围绕复选框设置逻辑，确定谁可以检查它们以及何时检查它们。

真实表格(有点傻，但这是一个例子):

  when checked  || may check Staff || may check Client   
 Staff | Client || Staff | Client  ||  Staff | Client 
  0        0    ||   1       0           0        1
  0        1    ||   0       0           0        1
  1        0    ||   1       0           0        1
  1        1    ||   0       0           0        1

有两个安全角色，员工和客户；一个人的角色决定了他们是谁，角色与复选框的当前状态一起保存在数据库中。

所以我可以简单地将用户滚动存储在 View 类中，并根据他们的角色启用和禁用复选框，但这似乎不合适。那就是在 UI 中放置逻辑来控制可以采取哪些操作。

我如何将大部分控制权下放到模型中？我的意思是我需要控制启用哪些复选框，然后在发布表单时检查模型中的结果，因此它似乎是它的最佳起点。

我正在寻找一种构建此应用程序的好方法，这是我构建应用程序时要遵循的方法。如果您知道一些很好的引用资料来解释这些最佳实践，那我们也非常感激。

Answer 1

我的方法倾向于编写 View ，以便用户可以做任何事情并将我所有的验证放在模型/服务层中。然后，当我让它完全正常工作时，我将添加 jQuery 逻辑，让用户更清楚地知道他们可以做什么和不能做什么，并在必要时避免不必要的回发。

我认为依赖浏览器来阻止服务器允许的某些内容是错误的。回发太容易伪造，javascript 很容易被关闭。但是，如果可以使用 javascript 来改善用户体验或节省服务器的工作量，您应该这样做。

是的，这有时确实意味着重复的业务逻辑，但这是值得做出的牺牲。它很少是实际的重复代码。服务器端是“如果X被选中，Y被选中，返回一个消息，不存储”，客户端是“如果X被选中，不允许Y被选中”。

有道理吗？