ASP.NET MVC Web应用程序中视图逻辑和域逻辑之间的混淆

Question

我在域/应用程序逻辑和用户界面逻辑之间感到困惑.为了说明我想要确定的内容,我将在下面描述一个虚构的程序用于说明目的:

(1)想象一个带有一组3级联下拉列表的小应用程序.当您选择一个下拉列表时,它会触发一个jQuery Ajax GET,最终命中MVC控制器,提供先前选择的下拉列表的选定值.控制器返回下一个下拉列表的允许选择.javacript(在视图中)将这些结果排列为下拉列表.等等.因此,每次选择下拉列表时,都会填充下一个下拉列表.

(2)现在扔扳手..有一些例外.假设用户在第一个下拉列表中选择"FOO"或"BAR",则行为会发生变化,因此第二个下拉列表将被禁用,而thrid下拉列表将显示一个texbox.

我的问题是,在MVC的背景下,这个"决策"逻辑的适当位置是什么？比如负责做出这些决定的代码,就像我在(2)中解释的那样.我一直把它放在最方便的地方是在视图的javascript中.我只是编写了javascript来测试第一个框是"FOO"还是"BAR"然后,禁用第二个dropwdown,并换掉文本框的第三个下拉列表.但这对我来说并不合适.因为它似乎应该是业务逻辑,因此代码应该属于某个地方的域层.但这也不是很正确.

所以我觉得我要进入圈子.有人可以对这个小设计有所了解吗？

Answer 1

让我们从领域模型开始吧.域模型是以与技术无关的方式对域进行建模的API.它对View技术一无所知,例如JQuery,HTML或(就此而言)XAML或Windows Forms.

域模型包含描述域的类和接口,并允许您以丰富且富有表现力的方式对域概念建模 - 无论您正在开发何种类型的应用程序.

考虑到这一点,很容易看出您描述的显示逻辑不属于域模型.因此,它必须属于特定于UI的层.

您可以将它放在单独的UI Logic模块中,也可以与UI应用程序一起使用 - 在您的情况下是ASP.NET MVC应用程序.无论是在JavaScript中还是在服务器端表达所需的UI逻辑都不太重要.

就个人而言,我会在Partial Views中定义这个逻辑服务器端,但这是因为我非常关心可测试性,而且我知道如何对这种行为进行单元测试(我被告知也可以单元测试JQuery代码,但我不知道这是不是真的.

如果您最终编写了基于相同域模型的另一个应用程序,那么显示逻辑很可能会变得非常不同,因为不同的技术意味着不同的范例.

Answer 2

不要吹毛求疵，也不要过于热衷于必须做什么来保持模式的纯粹......

显然，控制器知道必须发生此更改，因为它将处理两种结果情况（下拉选择或文本输入）。因此，将与此相关的逻辑放入控制器中并不是一种罪过。

同样明显的是，视图必须根据第一个下拉列表的内容更改其显示方式。虽然这种行为混合并不完全是我能想象的最佳 UI 体验，但如果必须满足需求，那么 UI 中必须存在一定程度的逻辑。但是，天哪，这就是我们在这里讨论的网站。您真的想从 javascript 中删除所有逻辑并将其移至控制器方法中吗？视图决定如何显示数据，这是它的工作，因此不能是罪过。

避免被烧死的真正方法是重新设计，从一开始就避免争议。或者，只是编码并一边喝啤酒一边抱怨你糟糕的设计要求。