2009-05-12 8 views
2

J'ai créé un framework pour un projet dans le passé dont l'une des fonctionnalités consistait à charger les informations de la base de données dans mes classes d'entité métier (uniquement les propriétés sans méthodes) et des classes d'entités métier aux base de données chargeant la collection de paramètres de la procédure stockée à exécuter. Pour cela sur ce projet j'ai décoré les Business Entity Classes avec l'information DB Filed et les paramètres SP comme l'exemple ci-dessous et laissez le framework charger l'entité ou la collection Parameters en utilisant la réflexion afin de ne pas générer de nouveau code pour les maintenances.
Mais maintenant je crée un nouveau et beaucoup plus grand projet, bien sûr beaucoup plus de code à maintenir, mais où la performance est critique et je me demandais si ça valait la peine d'utiliser la réflexion pour toute la charge et garder le code beaucoup plus simple. code et maintient tous les changements?
J'avais fait quelques recherches, lu de la documentation sur MSDN, mais j'ai trouvé beaucoup d'opinions différentes, des gens qui aimaient la réflexion montrant que les frais généraux ne sont pas si mauvais, et d'autres disant qu'il vaut mieux éviter la réflexion

spécifications techniques pour la nouvelle application:
langue: C#
.Net version: 3.5
type d'application: classique Web Forms accès aux composants logiques et de niveau d'accès aux données aussi en C#
Base de données: SQL Server 2008
Couche d'abstraction de base de données: Tous les accès à la base de données s'effectuent via des procédures stockées et des fonctions définies par l'utilisateur .


Exemple de code:
Performances de réflexion pour Data Access Layer

// 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); 

Répondre

4

Plutôt que de rouler ce qui est fondamentalement votre propre ORM, je recommande de passer à l'une des ORM établies telles que ou Entity Framework.

Pour répondre directement à votre question, les performances de réflexion ne sont pas si mauvaises, mais personnellement, je ne penserais jamais à utiliser un ORM que je me suis lancé dans un grand projet.

1

Personnellement, je n'utiliserais pas Reflection si les exigences d'accès aux données nécessitaient un grand nombre de transactions (un système hautement transactionnel) - ce que vous gagnez en flexibilité vous coûte en fin de compte (plus comment on reflection here).

Je choisirais un popular ORM solution par déférence pour une solution personnalisée. Principalement, vous bénéficierez d'une plus grande communauté de personnes utilisant les mêmes approches (plus facile d'obtenir des conseils de conception, de débogage et également tirer parti des réglages de performance connus).

Cela signifie généralement également l'accès aux mises à jour qui prennent en charge les nouvelles technologies (par exemple SQL Server 2008) telles qu'elles sont publiées: vous ne portez pas ce burdon ou le coût des tests (autre que l'implémentation directe).

Il y a un number of popular solutions incluant Entity Framework et LINQ to SQL (dans .Net 3.5 et tous les deux supportés Stored Procs) mais aussi beaucoup de support pour une approche basée sur template utilisant des templates CodeSmith/Net Tiers, ou plus compliquée solutions utilisant NHibernate ou Deklarit, par exemple. La dernière grande solution à laquelle j'ai participé utilisait des procédures stockées et des fonctions de la même manière que vous l'avez décrite, mais nous avons utilisé la bibliothèque d'entreprise et généré des classes d'accès DAL et des objets de transfert de données à l'aide d'un outil manuscrit. Vous pouvez utiliser à peu près la même approche que celle utilisée dans MS Web Service Software Factory 'potentiellement, ou toute approche basée sur un modèle.