Question

我与我的同行讨论了将存储库方法的搜索选项封装在对象或（可能增长的）参数列表中是否是一种好的做法。

总之，伪代码将是：

SearchItems(int id,string name,int statusId)

Vs的

class SearchOptions
{
   /*
   For illustration purposes, I intentionally made the, otherwise private fields public.
   Under normal circumstances, they would be private with their respective accessors or mutators or properties for C#
   */
   public int id;
   public string name;
   public int statusId;
}


SearchItems(SearchOptions filter)
{
   //Rest of code here
}

参数列表的参数是：

搜索只负责获得那时需要的结果。如果搜索要求应该改变，应该写一个具有特定功能的新方法。
即使对象参数表示它不那么突破，搜索选项中的任何更改仍然需要修改
跨平台集成更友好（例如，由于方法签名简单，Java服务后端到WCF服务后端）

让对象保存过滤器选项的参数是:(我的参数）

方法保持完整且灵活，无需破坏，工作量少，工作量少
方法签名中没有难看的长参数列表
接口保持不变，为减少更改次数增加了更多的重量

什么是好的做法？参数是否保持（双方）或者这是主观的吗？

Answer 1

参数列表的参数是：

搜索的唯一责任是仅获取此时所需的结果。如果搜索要求发生变化，则应编写具有特定功能的新方法。

如果Paramter对象专用于搜索方法，它也可以承担单一责任。 E.g。

class SearchByIdNameAndStatus { // Maybe you find a better name depending on your use case

   public int id;
   public string name;
   public int statusId;
}

即使对象参数表示它不那么突破，搜索选项中的任何更改仍然需要修改。

那是真的。此外......如果您在多种服务方法中使用一个参数对象，它们相互依赖。例如。如果更改参数对象，它可能会影响使用它的其他服务。

跨平台集成更友好（例如，由于方法签名的简单性，Java服务后端到WCF服务后端）

也许是。你真的有这个要求吗？您还可以在服务层顶部添加简单的传输层，以适应不同的传输。

让对象保存过滤器选项的参数是:(我的参数）

方法保持完整且灵活，不会破坏太多而且需要较少的工作。

我猜你的意思是你不会得到编译器错误，因为签名不会改变。但客户仍然必须设置＆＃34; new＆＃34;属性和服务必须解释它们。所以没有那么少的工作。

方法签名中没有难看的长参数列表

这是一个很好的论据。此外，您可以简单地定义哪些参数是强制的，哪些是可选的。使搜索参数对象的强制参数构造函数参数和可选的只是设置器。参数验证也可以在参数对象中完成。

接口保持不变，为减少更改次数增加了更多的重量

我想我之前已经回答了这个问题。

至少你可以看一下我写的博客，也许它可以帮助你在讨论中找到方法。参见

Answer 2

你实际上使用的是specification pattern，所以从文件记录的模式是好的做法，然后是的，这将被视为良好的做法。

存储库搜索中具有对象与参数列表的方法。违反SRP？

2 个答案: