将许多类似的参数封装到结构体中是否是良好的实践？

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服务的理解而言……这并不算太远）。

那么，这样做是否得不偿失，还是我正在做正确的事情呢？

- jpoh

Answer 1

除非您确实需要经常传递此参数集（使用相同的数据），否则我不认为有任何必要。长参数列表有时是需要重构代码的迹象，但有时又是不可避免的。（在您的情况下似乎更像后者。）因此，除非您发现自己需要存储参数集（至少是暂时的），否则只需直接传递参数即可 - 否则您真的不会节省任何代码，而且肯定不会增加可读性。

使用结构体的方法与 Web 服务没有任何限制。您只需要将类型设置为可序列化（在 WPF 中为 DataContract），就不应该有任何问题。

- Noldorin

---

值得注意的是，如果您想要为该方法添加一个重载，使用结构体方法将会很棘手。 - Noldorin

Answer 2

我总是把一组相关的参数放在一个对象中 - 这样代码更清晰，很明显它们彼此相关并且总是一起使用。

然而，在大多数情况下我使用类而不是结构体。结构体的好处从未让我明白，并且在许多情况下都很麻烦（我想Web服务场景只是一个例子）。

如果您不希望用户更改类，可以使其不可变（如果这是使用结构体的原因）。

- Grzenio

Answer 3

有一种被称为“封装上下文”的模式，谈论了使用这种技术涉及的问题。详细分析可以参考这里。

- Ed Sykes

Answer 4

我建议阅读关于结构体和值对象的这个问题

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

考虑到命名参数将在c# 4.0中出现，我建议像这样的任何东西只会在以后变得很烦人，除非有严重的需要在许多不同的地方传递这个“数据包”以及仅对它们有意义的操作。

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

- ShuggyCoUk

Answer 5

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

在我看来，在这种情况下创建一个类来保存信息并没有增加价值，但如果您计划对 DBParams 信息进行更复杂的操作（将其公开为 Webservice 的参数），则考虑使用对象。如果您只想以简洁的方式传递这些参数，则结构体就可以了。

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

http://discuss.joelonsoftware.com/default.asp?dotnet.12.489354.15

- mfcabrera