ASP.NET MVC Web 应用程序中视图逻辑和域逻辑之间的混淆 [英] Confusion between view logic and domain logic in a ASP.NET MVC Web Application

问题描述

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

I am getting confused between domain/application logic and User Interface logic. To illustrate what I am trying to nail down, I will describe an imaginary program below for illustration purposes:

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

(1) Imagine a small application with a set of 3 cascading drop-downs. As you select one dropdown it triggers a jQuery Ajax GET which ends up hitting a MVC controller, supplying the selected value of the previously selected drop-down. The controller returns the allowable choices for the next drop-down. The javacript (in the view) arranges these results into a drop-down. and so on. So each time you select a drop-down, the next one gets populated.

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

(2) Now throwing in a wrench.. There are some exceptions. Lets say if the user selects "FOO" or "BAR" in the first dropdown, then the behavor changes, so that the second dropdown is disabled, and the thrid dropdown will show a texbox instead.

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

My questions is, in the context of MVC, what is the appropriate place for this "decision" logic? Such as the code that is responsible for making these decisions like I explained in (2). The most convenient place that I have been putting this was right in the javascript of the view. I simply wrote javascript to test if the first box is "FOO" or "BAR" then, disable the second dropwdown, and swap out the third dropdown for a textbox. But this does not feel quite right to me. Because It seems like it should be business logic therefore the code should belong in a domain layer some place. But that does not feel quite right either.

所以我觉得我在兜圈子.有人能解释一下这个小设计吗?

And so I feel like I am going in circles. Can some one shed some light on this little design?

推荐答案

没有分裂太多头发或过于狂热于必须做什么才能保持图案纯净...

Without splitting too many hairs or getting too fanatical on WHAT MUST BE DONE TO KEEP THE PATTERN PURE...

显然控制器知道必须发生这种变化，因为它将处理两种结果情况(下拉选择或文本输入).因此，将与此相关的逻辑放在控制器中不是罪.

Obviously the Controller knows that this change must occur, as it will be handling both resulting cases (drop down selections or text entry). So putting logic relating to this in the Controller is not a sin.

同样明显的是，视图必须根据第一个下拉列表的内容更改其显示方式.虽然这种行为的混合并不是我能想象到的最好的 UI 体验，但如果必须的话，那么 UI 中必须存在某种程度的逻辑.但是，伙计们，这是我们在这里谈论的网站.您真的想从 javascript 中删除所有逻辑并将其移动到控制器方法中吗?视图决定如何显示数据，这是它的工作，因此不能成为罪.

It is also equally as obvious that the View must change how it displays depending on the contents of the first dropdown. While this mixing of behaviors isn't exactly the best UI experience I could imagine, if requirements must, then the logic for this must exist to some extent in the UI. But, jeez guys, this is a website we're talking about here. Do you really want to remove all logic from javascript and move it into a controller method? The View is deciding on how to display data, which is its job, and so cannot be a sin.

避免被烧毁的真正方法是重新设计，首先避免争议.或者，只是编写代码，然后在啤酒中抱怨您糟糕的设计要求.

The real way to avoid getting burnt at the stake is to redesign to avoid the controversy in the first place. Or, just code it and bitch about your lousy design requirements over a beer.

这篇关于ASP.NET MVC Web 应用程序中视图逻辑和域逻辑之间的混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！