5

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

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

或者

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

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

但它需要创建很多类似于getSelectedFileV 端的详细方法。

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

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

4

4 回答 4

8

第一种方法是我最喜欢的。唯一的区别是我宁愿使用一个对象（像马里奥建议的那样）将参数传递给该方法。当您添加或删除某些参数时，这种方法的签名不会改变。更少的耦合总是好的:)

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

于 2012-11-04T17:49:10.493 回答
6

第一种方法是要走的路；

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

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

虽然，我真的不知道如何String filePath = view.getSelectedFilePath();工作。我们是在谈论解析视图代码/标记吗？

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

那时您将创建一个 View Model 类（假设我们将其命名为MyViewModel）来存储您需要发送的所有属性（可能是 10 个属性），然后将其传递给 action: fileSelected(MyViewModel model)。这就是它的使用方式以及ModelBinderasp.net mvc 中的 * 可以帮助您。

于 2012-10-27T07:58:01.593 回答
2

我认为你需要退后一步来看待这个问题。

少担心它是如何进入的，而更关心验证和错误引发。

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

如果您专注于正确的验证，无论是在控制器内部（清理）还是在控制器外部（单元测试），那么您可以通过鸭子类型执行更彻底的解耦。

于 2012-11-05T04:05:39.963 回答
0

我会采用第一种方法。它是可重用的并且可以分离关注点。即使将来获取 filePath 的方法发生变化，也不会影响您的方法的功能。

于 2012-11-05T07:22:31.097 回答