我对域/应用程序逻辑和用户界面逻辑感到困惑。为了说明我想要确定的内容，我将在下面描述一个虚构的程序以供说明：
(1)
想象一个带有一组 3 个级联下拉菜单的小型应用程序。当您选择一个下拉列表时，它会触发 jQuery Ajax GET，最终到达 MVC 控制器，提供先前选择的下拉列表的选定值。控制器返回下一个下拉菜单允许的选择。 javacript（在视图中）将这些结果排列到下拉列表中。等等。因此，每次您选择一个下拉列表时，都会填充下一个下拉列表。
(2)
现在抛出一个扳手..有一些例外。假设用户在第一个下拉列表中选择“FOO”或“BAR”，则行为会发生变化，因此第二个下拉列表将被禁用，而第三个下拉列表将显示一个文本框。
我的问题是，在 MVC 的背景下，这个“决策”逻辑的合适位置在哪里？例如我在 (2) 中解释的负责做出这些决定的代码。我把它放在视图的 javascript 中最方便的地方。我只是编写了 javascript 来测试第一个框是“FOO”还是“BAR”，然后禁用第二个下拉列表，并将第三个下拉列表替换为文本框。但这对我来说感觉不太对劲。因为它看起来应该是业务逻辑，因此代码应该属于域层的某个地方。但这感觉也不太对劲。
所以我觉得我在兜圈子。有人可以解释一下这个小设计吗？
让我们从领域模型开始。领域模型是一种 API，以技术中立的方式对领域进行建模。它对 View 技术一无所知，例如 JQuery、HTML 或（就此而言）XAML 或 Windows 窗体。
领域模型包含描述领域的类和接口，并允许您以丰富且富有表现力的方式对领域概念进行建模 - 无论您正在开发什么类型的应用程序。
考虑到这一点，很容易看出您描述的显示逻辑不属于域模型。因此，它必须属于特定于 UI 的层。
你可以把它放在一个单独的UI Logic模块或与您的 UI 应用程序一起使用 - 在您的情况下是 ASP.NET MVC 应用程序。无论您是在 JavaScript 还是服务器端表达所需的 UI 逻辑，都不太重要。
就我个人而言，我会在部分视图中定义这个逻辑服务器端，但那是因为我非常关心可测试性，并且我知道如何对这种行为进行单元测试（有人告诉我也可以对 JQuery 代码进行单元测试，但我不知道这是否属实）。
如果您最终基于相同的域模型编写另一个应用程序，则显示逻辑很可能会非常不同，因为不同的技术意味着不同的范例。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
