Re: Java vs .NET was: RPGIII compiler vs Visual Basic

> date: Tue, 21 Jun 2005 12:54:33 -0400
> from: Steve Richter <stephenrichter@xxxxxxxxx>
> subject: Re: Java vs .NET was: RPGIII compiler vs Visual Basic

> > DBAccessManager db = new DBAccessManager(
> >        SWallTech.DB.DatabaseTypes.iSeriesDB2 ,
> >        datasource ,
> >        database ,
> >        userID ,
> >        password ,
> >        securityType );
> 
> looks great Joel, but it is too much code!  The strength of .NET is
> its simplicity and consistency.  A shop pays an extra $20 per month. 
> In return its team of $70 per hour contract programmers get their work
> done sooner which saves the enterprise a lot of money.

Too much code?  Why, because it takes parameters?  This is just
instantiating an object, how much simpler do you want it?  Your initial
complaint was needing to write different code for MySQL vs. SQL
Server... this way, you use the same class for ANY database you want to
access.  

The complexity is hidden: developing the connection string, creating the
xxxConnection object, creating and using xxxCommand objects, etc., are
all encompassed in the database classes, which you only have to develop
once.  To me, this is exactly the consistency and simplicity you are
looking for.  

> ( I was going to suggest you derive your data access classes from
> SqlCommand and SqlConnection.  But I see that MS has sealed those and
> many other .NET classes.  Which means they cant be derived.  Which
> makes it harder to use MySQL in .NET code! )
> 
> -Steve

The way ADO.NET works, you access the database you want through a
"Managed Provider".  That managed provider is a series of classes that
the database vendor (or some third party) wrote so that you can access
their database in .NET using the ADO standard.  As a result, they all
have their own class names:

iDB2Connection
MySqlConnection
SqlServerConnection
OracleConnection
OdbcConnectoin
OleDBConnection
PostgreSqlConnection
etc.

Each Database type has its own list of classes.  The "IBM DB2 UDB for
iSeries .Net Provider Technical Reference" lists the following classes:

iDB2Connection
iDB2Command
iDB2CommandBuilder
iDB2DataReader
iDB2DataAdapter
iDB2Parameter
iDB2ParameterCollection
iDB2Transaction
iDB2Exception
iDB2Error
iDB2ErrorCollection

These classes are all specific to iSeries DB2.  MySQL would have a
different list, SqlServer has its own list, etc.  So, even if I could
derive my classes from SqlServerConnection, they would ONLY be good for
accessing SQL Server databases.  It's no harder to use one of these for
MySQL than it is for SqlServer, or any other provider listed above, or
any of the hundreds of others available out there, they just have
different class names.  

What I've tried to create instead is a system for accessing ANY database
using the SAME code.  It's code reuse and inheritance doing what it does
best.  I did this specifically so I wouldn't have the complaint that you
(rightfully) registered earlier.  Now when I create a connection to a
database, I ALWAYS use the same class regardless of the Database, I just
pass it different parameters.  Here is an example of retrieving a
DataSet from a MySQL database:

DBAccessManager db = new DBAccessManager(
        SWallTech.DB.DatabaseTypes.MySQL ,
        "192.168.1.123" ,
        "myDB" ,
        "myUserID" ,
        "myPassword" ,
        null );

if ( db.IsConnected )
{
        DataSet ds = db.RunSQLStatement( "select * from myfile" );
}

Want to write the same code for your iSeries?

DBAccessManager db = new DBAccessManager(
        SWallTech.DB.DatabaseTypes.iSeriesDB2 ,
        "192.168.1.105" ,
        null ,
        "myUserID" ,
        "myPassword" ,
        null );

if ( db.IsConnected )
{
        DataSet ds = db.RunSQLStatement( "select * from mylib.myfile" );
}


If that is too much code for your contractors, then I suggest you get new 
contractors.

Joel