Overloading alternatives?

[Mike]

Hi,

Sorry I am new to object oriented.

I was trying to build a class from which I could retrieve DataSets, DataReader, execute SQL, etc. Some kind of SQL class. I thought that creating methods such as "RunSql" and "RunProc" would be a good idea, but then realized that it is not possible to create method overloading as follows:

public DataSet RunSql(string sSql, string sTableName)
public DataReader RunSql(string sSql)
public void RunSql(string sSql)

The above won't work, since the first two methods have the same signature. Is there a nice way of keeping the method name the same (RunSql) but return a different object? I was thinking about "Object" as return parameter, but won't there be a performance problem since casting is involved? Or should I just create different method with "getDataSet(...)", "getDataReader(...)", etc.?

Thanks
Mike

[Jon Skeet [C# MVP]]

Mike <no****@hotmail.com> wrote:

Sorry I am new to object oriented.

I was trying to build a class from which I could retrieve DataSets,
DataReader, execute SQL, etc. Some kind of SQL class. I thought that
creating methods such as "RunSql" and "RunProc" would be a good idea,
but then realized that it is not possible to create method overloading
as follows:

public DataSet RunSql(string sSql, string sTableName)
public DataReader RunSql(string sSql)
public void RunSql(string sSql)

The above won't work, since the first two methods have the same
signature. Is there a nice way of keeping the method name the same
(RunSql) but return a different object? I was thinking about "Object"
as return parameter, but won't there be a performance problem since
casting is involved? Or should I just create different method with
"getDataSet(...)", "getDataReader(...)", etc.?

Well, what's the difference between void RunSql and DataReader RunSql?
Where would you use one, and where would you use the other? An
appropriate name should be given to distinguish them for the developer
as well as the compiler.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike]

Jon,

I would use "void RunSql" to run a sql statement for which I don't need a
return value. The other "DataReader RunSql" would be used in situations
where I need a DataReader back. Do you think I should use the following
instead:

public void RunSql(string statement)
public DataReader ExecReaderSql(string statement)
public DataReader ExecReaderProc(string procname)
public DataSet ExecSetSql(string statement)
public DataSet ExecSetProc(string procname)

Thanks.

--
Michael

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike <no****@hotmail.com> wrote:

Sorry I am new to object oriented.

I was trying to build a class from which I could retrieve DataSets,
DataReader, execute SQL, etc. Some kind of SQL class. I thought that
creating methods such as "RunSql" and "RunProc" would be a good idea,
but then realized that it is not possible to create method overloading
as follows:

public DataSet RunSql(string sSql, string sTableName)
public DataReader RunSql(string sSql)
public void RunSql(string sSql)

The above won't work, since the first two methods have the same
signature. Is there a nice way of keeping the method name the same
(RunSql) but return a different object? I was thinking about "Object"
as return parameter, but won't there be a performance problem since
casting is involved? Or should I just create different method with
"getDataSet(...)", "getDataReader(...)", etc.?

Well, what's the difference between void RunSql and DataReader RunSql?
Where would you use one, and where would you use the other? An
appropriate name should be given to distinguish them for the developer
as well as the compiler.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Mike <no****@hotmail.com> wrote:

I would use "void RunSql" to run a sql statement for which I don't
need a return value. The other "DataReader RunSql" would be used in
situations where I need a DataReader back. Do you think I should use
the following instead:

public void RunSql(string statement)
public DataReader ExecReaderSql(string statement)
public DataReader ExecReaderProc(string procname)
public DataSet ExecSetSql(string statement)
public DataSet ExecSetProc(string procname)

That would seem reasonable, yes. You might want to look at IDbCommand,
and its ExecuteNonQuery, ExecuteReader etc methods for more
inspiration, too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Mike]

Thanks a lot.

--
Michael
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike <no****@hotmail.com> wrote:

I would use "void RunSql" to run a sql statement for which I don't
need a return value. The other "DataReader RunSql" would be used in
situations where I need a DataReader back. Do you think I should use
the following instead:

public void RunSql(string statement)
public DataReader ExecReaderSql(string statement)
public DataReader ExecReaderProc(string procname)
public DataSet ExecSetSql(string statement)
public DataSet ExecSetProc(string procname)

That would seem reasonable, yes. You might want to look at IDbCommand,
and its ExecuteNonQuery, ExecuteReader etc methods for more
inspiration, too.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeffrey Tan[MSFT]]

Hi Mike,

I am glad your problem resolved.

If you have further concern , please feel free to post, we will help you.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.