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

> date: Tue, 21 Jun 2005 14:18:34 -0400
> from: Steve Richter <stephenrichter@xxxxxxxxx>
> subject: Re: Java vs .NET was: RPGIII compiler vs Visual Basic
> 
> On 6/21/05, Joel Cochran <jrc@xxxxxxxxxx> wrote:
> > > 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 am curious to know how it would be done.  In the end however, the
> simplicity of using SQLServer only wins out.

I still don't get the "simplicity" argument.  How is this:

<SqlServer>
SqlConnection myCon = new SqlConnection( your_connectionString );
myCon.Open();
SqlCommand cmd = new SqlCommand( your_queryString , myCon );
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = cmd ;
DataSet ds = new DataSet( your_nameString );
da.Fill( ds , your_tableNameString );

any easier or harder than this:

<MySql>
MySqlConnection myCon = new MySqlConnection( your_connectionString );
myCon.Open();
MySqlCommand cmd = new MySqlCommand( your_queryString , myCon );
MySqlDataAdapter da = new MySqlDataAdapter();
da.SelectCommand = cmd ;
DataSet ds = new DataSet( your_nameString );
da.Fill( ds , your_tableNameString );

The only difference is in the class names.  I just don't see what the
big deal is. And again, my real point is that if you write some simple
wrappers, the ugliness and complexity of the above statements goes
away.  I had to go look these up because I just don't have to write that
kind of code anymore, I use my wrapper instead:

DBAccessManager db = new DBAccessManager(
        SWallTech.DB.DatabaseTypes.SqlServer ,
        datasource ,
        database ,
        userID ,
        password ,
        securityType );

if ( db.IsConnected )
{
        DataSet ds = db.RunSQLStatment( your_queryString );
}

I basically already said how it was done, but here is an outline:

1) Develop a generic Interface that includes the properties and methods
you would expect from Database access.
2) Develop a class for each database type you want to access that
Implements that Interface.  This is the Database dependant wrapper.
3) Develop a Master wrapper that also implements the Interface.  Have
that wrapper instantiate an Interface object based on the database type
you want.  Each method in the Mater wrapper then runs the same method
name on the instantiated database.  Use this wrapper in all Database
operations.

I know, I know "too much code"... develop this one time, put it in a
DLL, and never think about the details again.  If you work with multiple
database types, you'll love it.

> > 
> > If that is too much code for your contractors, then I suggest you get new 
> > contractors.
> > 
> 
> or use SQLServer as the sole database for .NET applications.

I'm not trying to flame, but that is just ridiculous.  I already have
three other databases installed and populated.  Now if I want to access
and manipulate that data in a DOTNET Windows Application I should
convert them all over to SQL Server?  Or worse yet, tell my employer
that he can't have that program he wants because the data isn't in SQL
Server?  If you really believe this, then I think we are at an impasse.

Joel