Question

基本上，我有以下内容：

public string SomeDBMethod(string server, string dbName, string userName, string password,...)

将其重构为以下内容是一种好习惯：

public string SomeDbMethod(DBParams parameters, ...)

DBParams的定义如下：

public struct DBParams
{
  string Server {get;set;}
  string DbName {get;set;}
  string UserName {get;set;}
  string Password {get;set;}
}

我的观点是能够传递较少的参数，因为我发现具有长参数列表的函数非常难看。

我还发现这种方法有一些限制：如果要将SomeDbMethod作为Web服务方法公开，我不能使用DBParams结构作为参数（就我对Web服务主题的理解而言） ......这不是很远。）

那么，这对于小小的好处来说是太麻烦还是我在这里做点什么？

Answer 1

除非你真的需要经常传递这组参数（使用相同的数据），否则我认为没有必要。长参数列表有时表明需要重构代码，但有时候再次有可能是不可避免的。（在你的情况下似乎更像后者。）所以，简单地使用直接传递参数的直接方法，除非你发现自己需要存储参数集（至少暂时） - 你真的不会保存任何代码否则，肯定不会提高可读性。

使用struct的方法不会对Web服务施加任何限制。您只需要将类型设置为可序列化（我相信在WPF中为DataContract），并且应该没有任何问题。

Answer 2

我总是将参数组合在一起成为一个对象 - 代码更加清晰，很明显它们彼此相关并且总是一起使用。

但是，在大多数情况下，我使用的是类，而不是结构。结构的好处对我来说从来都不清楚，在很多情况下它们都很痛苦（我猜网络服务场景只是一个例子）。

如果你不想让人们改变它，你可以使一个类成为不可变的（如果这是使用struct的原因）

Answer 3

有一种名为encapsulate context的模式，讨论了使用这种技术所涉及的问题。对于详细分析，可能值得一看。

Answer 4

在这种情况下，几乎可以肯定使结构可变是一个非常糟糕的主意。

鉴于命名参数是在c＃4.0中出现的，我建议这样的事情稍后会变得很烦人，应该避免，除非严重需要以多种不同的速度传递这个“信息包”信息。以及只对他们有意义的操作。

老实说，如果类/结构不维护/强制执行某些不变量，那么就没有什么意义了。

Answer 5

如果要封装相关变量，可以使用Struct。它不一定是一个对象。由于Structs是值类型，与类不同，它们不需要堆分配，它们也是通过值而不是像对象一样通过引用传递的。

在这种情况下，恕我直言创建一个类来保存该信息不会增加价值，但如果您计划使用DBParams信息（将其作为Web服务的参数公开）更复杂，那么请考虑使用对象。如果您想简单地以简洁的方式传递这些参数，那么结构就可以了。

您可以在此处获取更多信息：