Is it Generic Overkill to define multiple T types?

NOTE: I am mixing VB and C# - snippets come from different libraries

I have a VB class definition as follows:

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

I am wondering if this is too generic? There may be a better solution ...

Session has the responsibility of working with the desired set of classes: create connection strings, instance connections, and return datareaders. Instancing a session requires something like:

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

The constructors for session:

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 Dat开发者_如何学Goabase As String, ByVal UserID As String, ByVal Password As String)
    settings = New TConnectionBuilder()
    settings.Add("Server", Server)
    settings.Add("Database", Database)
    settings.Add("UserID", UserID)
    settings.Add("Password", Password)

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

DataReader is a custom generic class:

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

So, is this okay? Is there a more acceptable solution? The only thing that feels 'unwieldy' is instancing the initial session object.

 > Is it Generic Overkill to define multiple T types?

In general it is not as the in Dictionary<TKey, TValue> shows.

In your example the only reason you need generics is because you want to create objects of special types using the new operator. Everything else could be done by using the basetypes DbXxx instead of the Generic TXxx.

In your example i would use a factory instead of using generics. For the databaseworld microsoft has a buildin System.Data.Common.DbProviderFactory and DbProviderFactories that already provides most required functionality.

However writing portable code is quite difficuilt. For example your example contains

settings.Add("integrated security", True) 

that will only work for mssql

You should use DbProviderFactory Class

Check out Jean-Paul Boodhoo on Demystifying Design Patterns Part 5 - dnrTV which demonstrates usage.

And yes, it's an overkill usage of generics in this case.

not really - it depends on the situation. You have used constraints ... so it snot like you can ram anything into it. It is generic but for a specific set of classes which is fine. The class definition tells me a lot about what the session is going to work with.

if you want compile time checking then this makes sense.

The only problem with generics is that they can be a bit of a headache ... until you get used to them. howver the alternative is to use object and casting. I prefer to make as much fail at compile time as possible because then i have to test less (or rather that compiler does that work).

if you ever want a collection of 'session' objects independant of their type you may find that you have a problem though.

I dont think there is anything wrong with this. It means that you can test this class independantly of all the implementations of the constraints. It makes sense and is neat.

TBH id probably consider making it more generic and use the interfaces for the classes the constraints ... (IDBReader and IDBConnection for instance).

You could achieve a similar result through composition btw - id need to know what you are trying to do to figure out which is best in this situation.