Reflektionsleistung für Datenzugriffsschicht

Question

Ich hatte in der Vergangenheit ein Framework für ein Projekt erstellt, dessen eine Funktion darin bestand, die Datenbankinformationen in meine Business-Entitätsklassen (nur Eigenschaften keine Methoden) und von den Business-Entitätsklassen in die Datenbank zu laden Datenbank lädt die Parametersammlung der gespeicherten Prozedur, die ausgeführt werden soll. In diesem Projekt habe ich die Business Entity Classes mit den DB Filed Informationen und den SP Parametern wie im folgenden Beispiel dekoriert und das Framework die Entity oder die Parameters Collection mittels Reflection laden lassen, so dass ich keinen neuen Code für die Maintenance generieren musste.
Aber jetzt erstelle ich ein neues und viel größeres Projekt, natürlich viel mehr Code zu pflegen, aber wo Leistung ist kritisch und fragte mich, ob es sich lohnt, Reflexion für die gesamte Last und hielt den Code viel einfacher oder tatsächlich generieren alle Code und behalten Sie alle Änderungen bei?
Ich hatte einige suchen, lesen Sie einige der Dokumentation auf MSDN, aber immer noch viele verschiedene Meinungen gefunden, Leute, die Reflexion mit Zahlen, dass der Overhead nicht so schlecht ist, und andere sagen, dass es besser ist, sich von Reflexion zu vermeiden

Technische Spezifikationen für die neue App:
Sprache: C#
.Net Version: 3.5
Typ Anwendung: Klassische Web Forms Logik-Komponenten und Data Access Tier auch in C#
Datenbank Zugriff auf SQL Server 2008
Datenbankabstraktionsschicht: Der gesamte Zugriff auf die Datenbank erfolgt über Stored Procedures und User Defined Functions .


Beispielcode:

// Decorated class 
[System.Serializable()] 
public class bMyBusinessEntity{ 
    private Int64 _MyEntityID; 
    private string _MyEntityName; 
    private string _MyEntityDescription; 

    [aFieldDataSource(DataColumn = "MyEntityID")] 
    [aRequiredField(ErrorMessage = "The field My Entity ID is mandatory!")] 
    [aFieldSPParameter(ParameterName="MyEntityID")] 
    public Int64 MyEntityID{ 
     get { return _MyEntityID; } 
     set { _MyEntityID = value; } 
    } 

    [aFieldDataSource(DataColumn = "MyEntityName")] 
    [aFieldSPParameter(ParameterName = "MyEntityName")] 
    public string MyEntityName{ 
     get { return _MyEntityName; } 
     set { _MyEntityName = value; } 
    } 
    [aFieldDataSource(DataColumn = "MyEntityDescription")] 
    [aFieldSPParameter(ParameterName = "MyEntityDescription")] 
    public string MyEntityDescription{ 
     get { return _MyEntityDescription; } 
     set { _MyEntityDescription = value; } 
    } 
} 


    // To Load from DB to the Object: 
    using (DataTable dtblMyEntities = objDataSource.ExecuteProcedure(strSPName, objParams)) { 
     if (dtblMyEntities.Rows.Count > 0) { 
      DataRow drw = dtblMyEntities.Rows[0]; 
      oFieldDataSource.LoadInfo(ref objMyEntity, drw); 
      return objMyEntity; 
     } 
     else 
      throw new Exception(“Row not found!”); 
    } 

    // To Load from the Object to the DB 
    oDataSource objDataSource = new oDataSource(); 
    IDbDataParameter[] objParams = objDataSource.GetProcedureParameters(strSPName); 
    oFieldSPParameter.LoadInfo(objParams, objMyEntity); 
    objDataSource.ExecuteNonQuery(strSPName, objParams); 

Answer 1

Anstatt rollen, was im Grunde Ihre eigene ORM ist, würde ich empfehlen, zu einem der etablierten ORMs wie oder Entity Framework wechseln.

Um Ihre Frage direkt zu beantworten, ist die Reflektionsleistung nicht so schlecht, aber ich persönlich würde nie daran denken, ein ORM zu verwenden, das ich selbst in einem großen Projekt gerollt habe.

Answer 2

Ich persönlich würde Reflection nicht verwenden, wenn die Datenzugriffsanforderungen eine große Anzahl von Transaktionen erfordern (ein hochtransaktionelles System) - was Sie an Flexibilität gewinnen, kostet Sie letztendlich zur Laufzeit (mehr comment on reflection here).

Ich würde eine popular ORM solution in Bezug auf eine benutzerdefinierte Lösung wählen. Hauptsächlich profitieren Sie von einer größeren Gemeinschaft von Leuten, die dieselben Ansätze verwenden (einfacher, Design-Ratschläge zu erhalten, zu debuggen und auch bekannte Leistungsoptimierungen zu nutzen).

Es bedeutet in der Regel auch Zugriff auf Updates, die neuere Technologie (z. B. SQL Server 2008) unterstützt, wie es veröffentlicht wird - Sie tragen nicht diese Burdon oder die Kosten für das Testen (andere als direkte Implementierung).

Es gibt eine number of popular solutions einschließlich der Entity Framework und LINQ to SQL (in. Net 3.5 und beide unterstützen Stored Procs), sondern auch eine große Unterstützung für eine Vorlage-Ansatz mit CodeSmith Vorlagen/Net Tiers oder komplizierter B. mit NHibernate oder Deklarit.

Die letzte große Lösung, an der ich beteiligt war, verwendete Stored Procedures und Functions auf die gleiche Weise, die Sie beschrieben haben, jedoch verwendeten wir die Enterprise Library und generierten DAL-Zugriffsklassen und Datenübertragungsobjekte mit einem handgeschriebenen Werkzeug. Sie könnten den gleichen Ansatz verwenden, wie er in MS Patterns and Practices 'Web Service Software Factory' oder einem beliebigen Template-basierten Ansatz verwendet wird.