Best Practices für Datenzugriff mit IBM AS/400 und einem AS/400 .NET Data Provider

verwendetes Datenbanksystem: <IBM DB2>

Hallo zusammen,

ich habe mal ein paar Fragen zu den verschiedenen Datenbank-Zugriffsmethoden, bzw. möchte ich mir Klarheit verschaffen, weil ich das Gefühl habe immer etwas falsch zu machen.
Ich hole meine Daten immer, wie im folgenden Code aus der jeweiligen Datenquelle und speichere sie zur Weiterverarbeitung in einer DataTable (hier speziell das Beispiel IBM AS/400):

using IBM.Data.DB2.iSeries;

public static DataTable GetSQLData(string qry)
{

    // MessageBox.Show(conStr, "ConnectionString:");
    try
    {
        DataTable dt = new DataTable();

        using (iDB2Connection conn = new iDB2Connection(conStr)) 
        {
            conn.Open();

            iDB2Command cmd = new iDB2Command(qry, conn);
            iDB2DataReader reader;
            reader = cmd.ExecuteReader();
            dt.Load(reader);

            conn.Close();
            return dt;
        }
    }

    catch (Exception ex)
    {
        MessageBox.Show(ex.Message, "AS/400: Fehler bei SELECT");
        return null;
    }
}

Dieses DataTable kann ich mir dann über ein DataGridView anzeigen lassen oder die einzelnen DataRows auswerten.
Bisher konnte/kann ich damit gut arbeiten.

Schreibzugriffe auf die DB gingen auf ähnliche Weise bisher problemlos:

public static bool UpdateSQLData(string qry)
{

    try
    {
        using (iDB2Connection conn = new iDB2Connection(conStr))
        {
            conn.Open();

            iDB2Command cmd = new iDB2Command(qry, conn);
            cmd.ExecuteNonQuery();
            cmd.Dispose();                   

            return true;
        }
    }

    catch (Exception exp)
    {
        MessageBox.Show(exp.Message, "AS/400: Fehler bei UPDATE");

        return false;
    }
}

Im EntityFramework als Gegensatz wird ja die ORM-Technik verwendet, wo die entsprechenden DB-Tabellenstrukturen in eigenen Model-Klassen abgebildet (gemappt) werden.
Jeder Datensatz ist ja dann ein Objekt dieser Klasse. Ein sogenannter Kontext für die Model-Klasse liefert mir dann eine Collection (List, Dictionary...) aus den Objekten.
Mit diesem Dictionary wird dann per LINQ weitergearbeitet.

Für MS-Sql und MySql gibt es da ja freie Zugriffsmöglichkeiten aber für IBM AS/400 finde ich keinen freien AS400 .NET data provider und wir haben auch keinen lizenziert.
Ich bin also gezwungen über ODBC zu gehen. Dafür gibt es aber keine Unterstützung für das EntityFramework, wo es mir die Model-Klassen aus der DB erstellt.

Jetzt könnte ich mir die Model-Klassen ja per Hand tippen und die Kontexte dafür erstellen, was aber sehr aufwendig ist. Die Tabellen auf der AS/400 haben meist mehr als 50 Spalten.

Jetzt meine Fragen:

1. Sind meine oben genannten Zugriffsmethoden OK, zeitgemäß, sicher usw.? Wenn nicht - Was muss verbessert werden?
2. Macht es Sinn die riesigen Model-Klassen per Hand zu erstellen und sie per Kontext und LINQ zu verwenden?
3. Was ist der Vorteil von der Verwendung von EF und LINQ, wenn ich bisher mit meinen Zugriffsmethoden klar gekommen bin (Performance/Trennung Datenmodell von Logik)?

Gruß, NEUMee

Unabhängig von Deinen Punkten:

1. schau Dir den Repository Pattern an. Dein statischer Code da ist der erste Schritt ins Übel.
2. UI und Datenbank-Code zu vermischen ist der zweite Schritt ins Übel ( [Artikel] Drei-Schichten-Architektur )
3. schau Dir an was using() tut, dann wird automatisch der Code schlanker und übersichtlicher
4. Fehlerbehandlung. Wenn Du nur false zurück gibst weiß kein Mensch, was los ist; warum es nicht klappt

Soweit ich weiß gibt es für IBM AS einen ADO.NET Provider.
Da Entity Framework auf ADO.NET aufbaut, sollte das auch klappen.

Persönlich rate ich aber von Entity Framework ab und empfehle stets die Kombination von Dapper, Dapper.FastCrud und FluentMigrator.

Das Entity Framework für AS400 ist teuer : https://stackoverflow.com/questions/4546120/is-it-possible-to-use-entity-framework-with-a-db2-iseries-as-400

Hier ist die IBM Lizenz mit 12.000 Dollar angegeben.

Abhilfe : Einen Datenbank Provider für das Entity Framework selber schreiben !

ADO.NET wird natürlich heute noch genutzt, aber der untypisierte Umgang mit DataTable und Rows ist umständlich und fehlerbehaftet.

Ein Micro ORM wie Dapper kann ich auch empfehlen.

ODBC ist die langsamste und umständlichste Methode um auf eine Datenbank zuzugreifen. '

Grüße Bernd

@Abt

1. und 2. mache ich, habe nur noch Probleme, dies zu implementieren. Das ist doch der Weg über ORM?

2. OK, using macht try/catch/con.Close() überflüssig - werde ich.

3. Ich gebe doch auch den Wortlaut der Exception zurück, wenn auch per Direktzugriff auf das UI.
   Wie händle ich aber die Exception, wenn ich try/catch (siehe Punkt 3) weglasse?

@BerndFfm

OK, ich schaue mir Dapper mal an.

Danke euch!

1. und 2. mache ich, habe nur noch Probleme, dies zu implementieren.

Naja dem Code zufolge machst Du es nicht.

4. Ich gebe doch auch den Wortlaut der Exception zurück, wenn auch per Direktzugriff auf das UI.

Das ist in keinster Weise ein gutes Exception Handling.

Best practices for exceptions