定义多个T类型是否泛滥成灾？

如何解决定义多个T类型是否泛滥成灾？

| 注意：我正在混合VB和C＃-代码段来自不同的库我有一个VB类定义，如下所示：

Public Class Session(Of TConnectionBuilder As {DbConnectionStringBuilder,New},_
                         TConnection As {DbConnection,_
                         TDataReader As {DbDataReader})

我想知道这是否太通用？可能有更好的解决方案... 会话负责处理所需的一组类：创建连接字符串，实例连接和返回数据读取器。实例化会话需要类似以下内容：

session = new Session<SqlConnectionStringBuilder,SqlConnection,SqlDataReader>(@\"serverName\",\"dbName\");

会话的构造函数：

Private dataReader As DataReader(Of TConnection,TDataReader)
Private ReadOnly settings As TConnectionBuilder

//   assume integrated security
Public Sub New(ByVal Server As String,ByVal Database As String)
    settings = New TConnectionBuilder()
    settings.Add(\"Server\",Server)
    settings.Add(\"Database\",Database)
    settings.Add(\"integrated security\",True)

    dataReader = New DataReader(Of TConnection,TDataReader)(settings)
End Sub

Public Sub New(ByVal Server As String,ByVal Database As String,ByVal UserID As String,ByVal Password As String)
    settings = New TConnectionBuilder()
    settings.Add(\"Server\",Database)
    settings.Add(\"UserID\",UserID)
    settings.Add(\"Password\",Password)

    dataReader = New DataReader(Of TConnection,TDataReader)(settings)
End Sub

DataReader是一个自定义的通用类：

Friend Class DataReader(Of TConnection As {DbConnection,_
                            TDataReader As {DbDataReader})

那可以吗有更可接受的解决方案吗？唯一感觉到“笨拙”的是实例化初始会话对象。

解决方法

您应该使用DbProviderFactory类查阅Jean-Paul Boodhoo的Demystifying Design Patterns Part 5-dnrTV 演示用法。是的，在这种情况下，这是泛型的过度使用。 ,

 > Is it Generic Overkill to define multiple T types?

通常，它与Dictionary<TKey,TValue>中的不一样。在您的示例中，需要泛型的唯一原因是因为您想使用new运算符创建特殊类型的对象。通过使用基本类型by6ѭ而不是通用TXxx可以完成其他所有操作。在您的示例中，我将使用工厂而不是泛型。对于数据库世界，Microsoft具有一个内置的System.Data.Common.DbProviderFactory和DbProviderFactories，它们已经提供了大多数必需的功能。但是，编写可移植代码非常困难。例如，您的示例包含

settings.Add(\"integrated security\",True)

只适用于mssql ,不是真的-这取决于情况。您已经使用了约束...所以它听起来像您可以将任何内容塞入其中。它是通用的，但是对于一组特定的类来说很好。类的定义告诉我很多有关会话将要使用的内容。如果您要编译时检查，那么这很有意义。泛型的唯一问题是它们可能会让人头疼……直到您习惯了它们。但是，替代方法是使用对象和演员表。我宁愿在编译时尽可能地使失败，因为那样我就必须减少测试（或者说编译器可以完成此工作）。如果您想要独立于其类型的\'session \'对象的集合，则可能会发现您遇到了问题。我不认为这有什么问题。这意味着您可以独立于约束的所有实现来测试此类。这很有意义，而且很整洁。 TBH id可能考虑使其更通用，并使用约束类的接口...（例如IDBReader和IDBConnection）。您可以通过组合btw达到类似的结果-id需要知道您要尝试做什么才能找出在这种情况下最好的方法。

定义多个T类型是否泛滥成灾？

如何解决定义多个T类型是否泛滥成灾？

解决方法

相关推荐