我在域/应用程序逻辑和用户界面逻辑之间感到困惑。为了说明我试图确定的内容，我将在下面描述一个虚构的程序以进行说明:
(1)
想象一个带有一组 3 个级联下拉菜单的小型应用程序。当您选择一个下拉菜单时，它会触发一个 jQuery Ajax GET，该 GET 最终会到达一个 MVC Controller ，提供先前选择的下拉菜单的选定值。 Controller 为下一个下拉菜单返回允许的选项。 javacript(在 View 中)将这些结果排列到下拉列表中。等等。因此，每次您选择一个下拉菜单时，都会填充下一个。
(2)
现在扔 Spanner ..有一些异常(exception)。假设用户在第一个下拉列表中选择“FOO”或“BAR”，那么行为会发生变化，因此第二个下拉列表被禁用，第三个下拉列表将显示一个 texbox。
我的问题是，在 MVC 的上下文中，这个“决策”逻辑的合适位置是什么？比如我在 (2) 中解释的负责做出这些决定的代码。我把它放在最方便的地方就是在 View 的 javascript 中。我只是编写了javascript来测试第一个框是“FOO”还是“BAR”，然后禁用第二个下拉菜单，并将第三个下拉菜单换成文本框。但这对我来说并不完全正确。因为它看起来应该是业务逻辑，因此代码应该属于某个地方的域层。但这也感觉不太对。
所以我觉得我在绕圈子。有人能解释一下这个小设计吗？
最佳答案
让我们从领域模型开始。域模型是一种 API，它以技术中立的方式对域进行建模。它对诸如 JQuery、HTML 或(就此而言)XAML 或 Windows 窗体之类的 View 技术一无所知。
域模型包含描述域的类和接口(interface)，并允许您以丰富和富有表现力的方式对域概念进行建模——无论您正在开发什么类型的应用程序。
考虑到这一点，很容易看出您描述的显示逻辑不属于域模型。因此，它必须属于特定于 UI 的层。
您可以将它放在一个单独的 UI 逻辑模块中或与您的 UI 应用程序一起 - 在您的情况下是一个 ASP.NET MVC 应用程序。是在 JavaScript 还是在服务器端表达所需的 UI 逻辑并不重要。
就个人而言，我会在 Partial Views 中定义这个逻辑服务器端，但那是因为我非常关心可测试性，而且我知道如何对这种行为进行单元测试(有人告诉我也可以对 JQuery 代码进行单元测试，但我不知道这是否属实)。
如果您最终基于相同的域模型编写另一个应用程序，那么显示逻辑很可能会变得非常不同，因为不同的技术意味着不同的范例。
关于asp.net - ASP.NET MVC Web 应用程序中的 View 逻辑和域逻辑之间的混淆，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1948760/