Nous avons une application qui permet à l'utilisateur d'ajouter des colonnes personnalisées à nos tables (ce n'est peut-être pas la meilleure idée, mais c'est comme ça).Lecture de données personnalisées à partir de tables SQL
Nous sommes en train de (re) concevoir notre couche dataaccess (nous n'en avions pas vraiment) et maintenant nous allons utiliser des requêtes paramétrées dans nos datamappers lors de l'interrogation de la base de données SQL (plus tôt nous avons concaténé chaînes et échappé à toutes les entrées).
Maintenant, nous essayons de déterminer la meilleure façon de gérer les colonnes personnalisées afin d'interroger, créer et mettre à jour ces enregistrements. Les attributs personnalisés vont être stockés dans un dictionnaire sur nos « objets métier » donc je pensais à le faire comme ceci:
données Interrogation
- Utilisez SELECT * pour obtenir toutes les colonnes et remplir nos propriétés et stocker le reste (données personnalisées) dans un dictionnaire sur l'objet métier.
Créer/Mettre à jour
- Itérer toutes les colonnes de la table (quelque chose comme: SELECT COLUMN_NAME DE INFORMATION_SCHEMA.COLUMNS OU TABLE_NAME = 'TableName'
- Générer une chaîne SQL (avec paramétrés variablenames) en vérifiant quelles colonnes existent à la fois dans le dictionnaire et dans la table, puis en ajoutant les valeurs du dictionnaire en tant que variables à la commande SQLC
Ou existe-t-il de meilleures approches tout en utilisant des requêtes paramétrées?
De meilleures approches comme l'utilisation d'un ORM comme NHibernate? –
Oui, j'ai aussi pensé à ça. NHibernate peut-il gérer les données personnalisées qui ne sont pas présentes sur compiletime? Est-il facile de le rendre personnalisable pour un "utilisateur final" sans rien exiger d'autre que d'ajouter une colonne dans SQL Management Studio? – Per
Re ORM: le problème est que la plupart des ORM veulent écrire dans un membre. Ce qui pourrait signifier écrire des types à l'exécution ('TypeBuilder') - assez complexe + dur. Pas gentil. –