Quels facteurs doivent affecter la couche d'accès aux données que j'utilise sur un nouveau projet?

Question

Je vais enseigner à un étudiant en classe, et je dois expliquer quels facteurs devraient influer sur votre décision d'utiliser la technologie d'accès aux données. Je connais bien de nombreuses méthodes d'accès aux données, telles que les ensembles de données typées, Linq to SQL, Linq to Entities, .netTiers, LLBLGen et les appels personnalisés avec des objets de connexion SQL et des objets de commande. Certains de mes clients n'autoriseront que l'utilisation de procédures stockées et ne discuteront de rien d'autre. Certains de mes clients ne sont PAS encore prêts à installer .NET 3.5. Certains clients requièrent un niveau de service Web intermédiaire dans toute application Web. La plupart du temps, j'utilise des types de jeux de données et des services Web personnalisés ou j'utilise .netTiers avec CodeSmith. À quoi d'autre devrais-je penser?

Answer 1

Comme avec tout choix dans un projet logiciel: ça dépend ... Mais à mon avis, le facteur le plus important est l’environnement du projet.

Ceci consiste en (je ne prétends pas que cette liste est complète de toute façon):

• Compétences disponibles au sein de l'équipe de développement ET de l'équipe de maintenance (si différentes)
• Fonctionnalités requises
• Contraintes définies par les clients (tous les clients ne prennent pas en charge toutes les technologies disponibles. Ceci doit certainement être pris en compte lors du remplacement incrémentiel d'un système existant ou de l'introduction d'un nouveau système dans un environnement)
• Contraintes définies par la législation

espérons que cela vous aide.

Answer 2

Une chose importante à garder à l'esprit est qu'une base de données n'est pas nécessairement un simple magasin de données de sauvegarde pour une application (isolée). D’autres applications et processus pourraient éventuellement nécessiter un accès à la base de données, en particulier dans les bases de données volumineuses ou «d'entreprise» (ou applications) et surtout s’ils disposaient d’un délai suffisant.

Il est important de prendre en compte:

ETL / Loads / Migration

Intégration / synchronisation externe (BizTalk / SSIS)

Réutilisation par d'autres applications (notamment sites Web, applications mobiles, etc.)

Surface de sécurité / attaque (une approche est-elle moins sûre qu'une autre?)

Tâches de maintenance

Disponibilité - la base de données sera-t-elle utilisée 24h / 24 et 7j / 7? Une approche offrira-t-elle une meilleure disponibilité qu'une autre, etc.

De plus, certaines considérations de conception sont en ordre. Êtes-vous à l’accord pour des sélections ou des écritures plus rapides? Un modèle d’accès aux données peut être plus performant qu’un autre.

Je ne dis pas qu'il existe une seule solution miracle, mais ce que je vous fais remarquer, c'est que tout modèle de conception d'accès aux données nécessite une vue d'ensemble - pensera-t-il qu'il répondra aux préoccupations d'aujourd'hui et que vous pouvez raisonnablement prédire qu'il pourrait s'agir des besoins de demain? ?

De plus, proposerez-vous une API externe ou un cadre pour un accès cohérent aux données? Sera-t-il exposé directement ou indirectement?

Je pense qu’il existe une place à la fois pour Entity Framework / LINQ to SQL, les procédures stockées traditionnelles et d’autres outils tels que NHibernate (etc.), mais vous devez d’abord justifier et rationaliser le choix de la technologie, puis essayer de vous en assurer. adapté aux besoins présents et futurs.

EDIT: Désolé, j'ai oublié le gros problème: la maintenabilité. Certaines des solutions basées sur des modèles vous offrent des avantages décents pour pouvoir régénérer un DAL après des modifications de schéma, par rapport à d’autres (comme des procédures stockées écrites à la main). Il convient de peser les gains de productivité par rapport aux inconvénients.

Answer 3

Je pense qu'entre votre message d'origine et les ajouts de norbertB, vous avez couvert à peu près tout. Commencez avec les contraintes absolues (et rappelez-vous que ce n'est pas parce qu'un client dit non à quelque chose une fois - même s'il dit que c'est absolu - que vous ne pouvez pas vous empêcher de changer d'avis ...). Une fois que vous avez réduit le champ avec les contraintes absolues, regardez les autres choses.

Une chose qui semblait être laissée de côté était la flexibilité. Par exemple, si j'essayais de choisir entre deux technologies similaires et que je savais que l'une pouvait prendre en charge les vues modifiables et l'autre, même si je n'avais absolument pas besoin de vues modifiables à l'époque, je m'approcherais toujours de celle-ci " juste au cas où.

Answer 4

Je ne pense vraiment qu'à deux choses. Le premier est de savoir si je vais avoir tellement de données que toute autre chose compte. Si vous ne mettez pas des millions de lignes dans les tables, peu importe la technologie que vous utiliserez, elles fonctionneront toutes assez rapidement.

La deuxième chose est de savoir si je peux utiliser LINQ, parce que je trouve qu'utiliser LINQ (en SQL, en Entités, en LLBLGen, peu importe) pour interroger la base de données vous donne deux choses importantes. La première est qu'il est très facile d'écrire des requêtes et deuxièmement, il est assez facile de basculer entre deux frameworks nécessitant LINQ, au cas où les exigences changent.