Question

鉴于视图上有文件选择小部件，控制器需要处理选择文件的事件，我是否应该编写控制器方法：

public void fileSelected(String filePath){
  //process filePath
}

或

public void fileSelected(){
  String filePath = view.getSelectedFilePath();
  //process filePath
}

第一种方法似乎在C和V之间引入了较少的耦合：C不知道C在处理给定事件时究竟需要什么数据。

但它需要在V侧创建许多类似于getSelectedFile的详细方法。

另一方面，第二种方法可能会导致比实例更复杂的情况下混乱的控制器方法（传递的数据要比filePath多得多）。

根据您自己的经验，您更喜欢哪种方式？

Answer 1

第一种方法是我的最爱。唯一的区别是我宁愿使用一个对象（如Mario建议的）将参数传递给方法。这样，当您添加或删除某些参数时，方法的签名不会更改。较少的耦合总是好的：）

还有一件事：如果您想尝试第二种解决方案，我建议使用ViewFactory从控制器中删除视图逻辑。

Answer 2

第一种方法是要走的路;

public void fileSelected(String filePath){
  //process filePath
}

Controller不应关心View的外观或实现方式。在创建/更新视图时，开发人员也可以更清楚地了解控制器中的操作。它也使方法重载更容易。

尽管如此，我真的不知道String filePath = view.getSelectedFilePath();会如何运作。我们是在谈论解析View代码/标记吗？

另一方面，第二种方法可能会导致比实例更复杂的情况下更混乱的控制器方法（要传递的数据远远超过filePath）。

那时你要创建一个View Model类（假设我们将它命名为MyViewModel）来存储你需要发送的所有属性（可能是10个属性），然后在动作中传递它：{ {1}}。这就是它的用途以及asp.net mvc中* fileSelected(MyViewModel model)的帮助。

Answer 3

我认为你需要退一步看看。

不要担心它是如何进入的，并且更关注验证和错误提升。

明天，您的要求可能会发生变化，并要求您通过不同的架构方法获取信息。您可以将[输入/输入对象]的设置重构为基本控制器类 - 或者为不同控制器域重构几个类之一。

如果您专注于正确的验证，无论是在控制器内（擦洗）还是在控制之外（单元测试），那么您可以通过duck typing执行更彻底的解耦。

Answer 4

我会采用第一种方法。它可以重复使用，并将问题分开。即使将来获取filePath的方法发生了变化，也不会影响方法的功能。