代码之家 › 专栏 › 技术社区 › Brettski

应用业务逻辑在asp.net mvc中形成元素

model-view-controller security asp.net-mvc

Brettski · 技术社区 · 16 年前

我正在寻找应用业务逻辑在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

有两个安全角色,staff和client;一个人的角色决定了他们是谁,这些角色和复选框的当前状态一起维护在数据库中。

因此,我可以简单地将用户的roll存储在view类中,并根据其角色启用和禁用复选框,但这似乎不正确。这就是在ui中放置逻辑来控制可以采取哪些操作。

如何将此控件的大部分降到模型中?我的意思是我需要控制哪些复选框被启用,然后在发布表单时检查模型中的结果,所以它似乎是最好的来源。

我正在寻找一个好的方法来构建这个,在我构建应用程序时需要遵循的一些东西。如果你知道一些很好的参考资料,其中解释了这些最佳做法,真的很感激。

2 回复 | 直到 16 年前

pdr 16 年前

我的方法倾向于编写视图,这样用户可以做任何事情,并将我的所有验证放在模型/服务层中。然后,当我完成了这项工作后,我将添加jquery逻辑,让用户更清楚地知道他们能做什么和不能做什么,并在必要时避免不必要的回发。

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

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

有道理?

griegs 16 年前

如果您想将ui的所有构建保持在模型中,那么您可能需要在每个复选框中包含一个状态。因此,您的模型将包含一个checkbox对象,而checkbox对象又具有state属性。

然后在您的视图中,您可以使用model.checkboxname.state设置enabled标志。

然后,对于每一个需要状态信息的控件,这都是正确的,我认为这会使您的模型过于复杂。

就我个人而言,我会在视图中保留一些智能,因为不是所有使用此模型的视图都需要状态标志。

imo模型应该尽可能简单。您可以使用一个formviewmodel来描述各种控件的状态,这些控件将从模型中移除状态,我认为这是一个好主意。

@PDR提出了一个很好的观点,与其有一个禁用的复选框,不如考虑有一个标签。但你还是有假装回邮的问题。

这很容易捕获,因为您的formviewmodel可以告诉您是否忽略来自禁用控件的提交。

不管怎样,如果你想在模型中使用这个,那么我将创建一个formviewmodel并在其中包含状态。我也会在邮件中检查您是否可以接受来自已解散控件的值。