Je suis en train de planifier une application de base de données pour un usage personnel. J'ai une bonne partie de la structure de la base de données planifiée, mais comme je pense à la façon dont je vais écrire le programme, je me suis demandé si je faisais cela dans le bon ordre.Planification d'une application de base de données
Que devrais-je planifier en premier, la structure db ou les classes?
Je pense que la conception de votre modèle de données premier C'est une très bonne idée.
Si l'application doit être pilotée par une base de données, il est conseillé d'avoir une bonne compréhension de ce à quoi ressemblera votre modèle de données avant même d'essayer d'écrire du code.
Vous pouvez toujours conceptualiser la façon dont vous pensez que les classes peuvent vous donner une idée de votre modèle de données. Garder cela dans le dos de votre esprit lorsque vous déterminez vos besoins vous aidera lorsque vous commencez à écrire du code ainsi. Bien sûr, lorsque vous commencerez à écrire du code, vous devrez probablement revoir votre structure de données. Il s'agit donc d'un processus itératif, mais une bonne planification dès le début du projet est une bonne idée.
Ils se développent le plus souvent ensemble, bien qu'il soit souvent plus facile de commencer à concevoir la structure de base de la base de données, puis de passer au code. Vous constaterez que selon la taille de votre application, la base de données changera fréquemment en cours de route vers le produit final.
Je planifie généralement de mon mieux, puis je commence à créer la base de données en fonction des spécifications de planification/conception que j'ai écrites pour moi-même.
Ensuite, j'utilise quelque chose comme Linq-To-SQL pour générer des classes DAL de base - les envelopper dans une classe de référentiel qui gère la plupart de mes situations CRUD. En fonction de la complexité de l'application, j'écris alors une interface graphique qui consomme le référentiel directement (rapide/sale) ou j'écris une classe de logique de domaine (et potentiellement des objets de transfert de données ou POCO stupides) qui enveloppe le fonctionnalité dans le référentiel.
De toute évidence, la meilleure planification des choses manque, alors assurez-vous de prendre pour compte que vous devrez revenir en arrière et ajouter des champs, modifier les types, ajouter des relations etc.
Ceci est intéressant, et je pense que je comprends ce que vous voulez dire, mais c'est surtout sur ma tête. Voulez-vous dire qu'après la planification, après avoir créé un ORM, puis écrire du code pour votre ORM? – ChrisC
Oui, à peu près. Planifier, construire dans SQL Server, configurer Linq-To-SQL, puis commencer à coder autour de cela. – Nate
Je pense que vous obtiendrez une réponse différente des personnes centrées sur l'application de données centrées sur le client. Personnellement, je commence toujours avec les données, mais un programmeur d'application commence probablement avec les classes.
En réalité, je pense que vous devez travailler sur les deux en même temps.
+1: Toujours commencer par les données. –
Si le but de votre système est de stocker, extraire et rapporter des données, alors je dirais qu'il est tout à fait approprié de concevoir la base de données en premier. Si, d'un autre côté, le but du système est de mettre en œuvre un processus métier ou des processus utilisant un logiciel, il sera souvent plus efficace de concevoir le "modèle de domaine" en modélisant le processus métier en objets./classes, puis déterminer comment les persister vers/depuis une base de données plus tard.
+1: Les données demeurent à jamais, le traitement va et vient. –
@S.Lott - c'est une bonne citation, je vais devoir me rappeler que – jaywon