如何避免界面中的“相同签名错误”？答案

【问题标题】：How to avoid 'the same signature error' in interface?如何避免界面中的“相同签名错误”？
【发布时间】：2016-09-18 21:22:32
【问题描述】：

我正在为 n 层应用程序建模域接口并准备接口 ICustomerRepository。在里面我有很多签名，其中两个面临“相同签名”错误。

    Customer GetCustomer(string guid, CustomerInformationLevel informationLevel
        = CustomerInformationLevel.AccountInformation);

    Customer GetCustomer(string firstName, string lastName, string middleName,
        CustomerInformationLevel informationLevel
            = CustomerInformationLevel.AccountInformation);

    Customer GetCustomer(string email, CustomerInformationLevel informationLevel
        = CustomerInformationLevel.AccountInformation);

与 string 'guid' 和 'email' 的签名冲突。我知道它为什么会发生，但不知道如何在正确的架构和设计原则的背景下避免它。

【问题讨论】：

也许使用类型Guid作为参数guid？
或者有称为GetCustomerById、GetCustomerByName和GetCustomerByEmail的方法。
或者更确切地说使用 Email 类作为电子邮件，因为稍后在它自己的类中对其进行验证是有意义的。
string[] names 对于第二个将是另一种方式。不同的方法名称虽然更清楚
这两种方法具有完全相同的签名。参数名称对方法签名没有贡献。因此，您不会通过使用不同的参数名称来获得不同的签名。

标签： c# web-services design-patterns n-tier-architecture

【解决方案1】：

您可以在第一种方法中使用Guid 而不是string，然后将Guid 变量解析为字符串。
您可以对 guid 和 email 使用相同的方法，并检查在此方法中传递的参数类型（使用正则表达式或检查字符串是否包含“@”符号）并通过特定方式处理 email 和 guid。
为第一种和第三种方法设置不同的名称

如果您希望方法名称相同，则应选择第一个或第二个选项。

如果您将 guid 存储在应用程序中的字符串中，最好使用第二个选项。
如果使用什么类型（Guid 或 string）并不重要，那么第一个选项会更好（但这是我的看法）

【讨论】：

我将在 Entity Framework 中使用代码优先，因此我认为将 guid 存储为字符串对于 EF 和 MS SQL 会更加性能优化。我是对的还是 guid\string 类型映射到 MS SQL 之间没有区别？
Guid 的 SQL 类型是字符串 - stackoverflow.com/questions/1435908/…