As you can see, such interface deals with 4 ADO.NET data types for PostgreSQL DB (PgSqlConnection, PgSqlTransaction, PgSqlCommand and PgSqlDataReader) from a specific manufacturer of data providers.
If I use another data provider manufacturer or another database, these types will change so I would need to create another interface if I keep the syntax shown above. My goal is to have only 1 interface for simplicity and also because I guess it is a good
programming practice. To achieve such goal I see that (one choice) can be to use arguments for the interface so that it can be rewritten as follows:
public interface IExample<T, U, V, W>
{
Task<T> GetConnectionObject();
U GetTransactionObject(T pgConn);
V GetCommandObject(T pgConn, U pgTrans, bool isTransactionable);
void Save(T pgConn, V pgCmd);
void SaveT(T pgConn, V pgCmd, U pgTrans);
W GetReader(T pgConn, V pgCmd);
}
In this case, T would be for PgSqlConnection,
U for PgSqlTransaction, V for PgSqlCommand and
W for PgSqlDataReader.
If I need to use a different DB of ASP.NET data provider manufacturer I would match T, U, V and W accordingly for Connection, Transaction, Command and DataReader.
If I need to use a different DB of ASP.NET data provider manufacturer I would match T, U, V and W accordingly for Connection, Transaction, Command and DataReader.
According to this description, the second one which with generics should be the better choice since you said you want to change the DB of ASP.NET data provider manufacturer. In fact, if you don't choose the second approach, you might need to cteate multiple
similar interfaces for different manufacturers.
Do you need the specific types you mentioned? I notice that, for example, PgSqlConnection implements the IDbConnection interface. Can you make your interface be
I haven't checked the other classes you mention but expect there will be similar possibilities.
If you really need some aspect of PgSqlConnection that is not specified by IDbConnection then you could handle that in the concrete implementations. But, generally speaking, that would be a code smell that you should avoid.
If you are dependent on a higher level of abstraction it will be much easier to use other concrete classes at a later stage. (In the best case classes which implement IExample will not need to change at all)
Thanks to Yang Shen and PaulTheSmith for your answers. Both helped me to get a broader concept of my situation and learned a lot to provide solutions to future issues.
I finally took Yang Shen option because I needed the concrete types but PaulTheSmith choice was enlightening. This is the reason I marked both as answers.
Member
71 Points
351 Posts
Is it a good practice to define an interface with several type arguments?
Mar 17, 2020 06:21 PM|JORGEMAL|LINK
Hi,
I am using an Interface as follows:
public interface IExample { Task<PgSqlConnection> GetConnectionObject(); PgSqlTransaction GetTransactionObject(PgSqlConnection pgConn); PgSqlCommand GetCommandObject(PgSqlConnection pgConn, PgSqlTransaction pgTrans, bool isTransactionable); void Save(PgSqlConnection pgConn, PgSqlCommand pgCmd); void SaveT(PgSqlConnection pgConn, PgSqlCommand pgCmd, PgSqlTransaction pgTrans); PgSqlDataReader GetReader(PgSqlConnection pgConn, PgSqlCommand pgCmd); }As you can see, such interface deals with 4 ADO.NET data types for PostgreSQL DB (PgSqlConnection, PgSqlTransaction, PgSqlCommand and PgSqlDataReader) from a specific manufacturer of data providers.
If I use another data provider manufacturer or another database, these types will change so I would need to create another interface if I keep the syntax shown above. My goal is to have only 1 interface for simplicity and also because I guess it is a good programming practice. To achieve such goal I see that (one choice) can be to use arguments for the interface so that it can be rewritten as follows:
public interface IExample<T, U, V, W> { Task<T> GetConnectionObject(); U GetTransactionObject(T pgConn); V GetCommandObject(T pgConn, U pgTrans, bool isTransactionable); void Save(T pgConn, V pgCmd); void SaveT(T pgConn, V pgCmd, U pgTrans); W GetReader(T pgConn, V pgCmd); }In this case, T would be for PgSqlConnection, U for PgSqlTransaction, V for PgSqlCommand and W for PgSqlDataReader.
If I need to use a different DB of ASP.NET data provider manufacturer I would match T, U, V and W accordingly for Connection, Transaction, Command and DataReader.
My question: is this a good approach?
Respectfully,
Jorge Maldonado
Contributor
3140 Points
983 Posts
Re: Is it a good practice to define an interface with several type arguments?
Mar 18, 2020 03:40 AM|Yang Shen|LINK
Hi JORGEMAL,
According to this description, the second one which with generics should be the better choice since you said you want to change the DB of ASP.NET data provider manufacturer. In fact, if you don't choose the second approach, you might need to cteate multiple similar interfaces for different manufacturers.
Best Regard,
Yang Shen
Participant
1620 Points
927 Posts
Re: Is it a good practice to define an interface with several type arguments?
Mar 18, 2020 06:55 AM|PaulTheSmith|LINK
Do you need the specific types you mentioned? I notice that, for example, PgSqlConnection implements the IDbConnection interface. Can you make your interface be
Task<System.Data.IDbConnection> GetConnectionObject();
Similarly PgSqlTransaction implements System.Data.IDbTransaction
I haven't checked the other classes you mention but expect there will be similar possibilities.
If you really need some aspect of PgSqlConnection that is not specified by IDbConnection then you could handle that in the concrete implementations. But, generally speaking, that would be a code smell that you should avoid.
If you are dependent on a higher level of abstraction it will be much easier to use other concrete classes at a later stage. (In the best case classes which implement IExample will not need to change at all)
My 2c
Member
71 Points
351 Posts
Re: Is it a good practice to define an interface with several type arguments?
Mar 23, 2020 02:49 PM|JORGEMAL|LINK
Thanks to Yang Shen and PaulTheSmith for your answers. Both helped me to get a broader concept of my situation and learned a lot to provide solutions to future issues.
I finally took Yang Shen option because I needed the concrete types but PaulTheSmith choice was enlightening. This is the reason I marked both as answers.
Best regards,
Jorge Maldonado