Code-First ou Database-First, comment choisir ?

Question

Supposons que nous allons commencer un nouveau projet - une application qui contient une logique d'entreprise, une interface utilisateur sur ASP.NET, WPF ou les deux. Nous aimerions utiliser un générateur de code ORM ou DAL et implémenter notre logique métier dans des classes .NET. Il existe plusieurs façons fondamentales d'exprimer nos idées dans le domaine des affaires :

• Implémenter des classes métier sur .NET et laisser ORM générer le schéma de base de données approprié.
• Créer manuellement un schéma de base de données et générer des classes .NET par le générateur de code
• Utilisez une sorte de concepteur visuel, qui peut générer des classes d'affaires et une structure de base de données ou un script.

Qu'est-ce que vous préférez écrire : "Créer une table Personnes ( ... )" ou "public class Person { ... }" ?
Quels sont les avantages et les inconvénients de ces méthodes ?
Peut-être existe-t-il des situations particulières où une méthode est meilleure qu'une autre ?
Comment choisir la voie optimale dans un projet particulier ?

Je suis assez familier avec la méthode "Code-First" (ou "Model-First"), mais il semble que la plupart des ORM soient conçus comme des générateurs de code ou des mappeurs, ce qui suppose que j'implémente manuellement à la fois la structure de la base de données et les classes métier.

Les réponses basées sur l'expérience et les exemples d'ORM sont particulièrement bienvenues.

Edit : Remarque : la question n'est pas "Que dois-je faire en premier lorsque je démarre un nouveau projet ?", mais "Que faut-il déclarer manuellement / générer automatiquement, les classes du domaine ou la structure de la base de données ?".

Answer 1

Je pense que l'approche appropriée pour l'analyse et la conception de systèmes consiste à commencer par modéliser vos objets et les relations entre eux. Si vous créez un système de bibliothèque, vous devez considérer les expressions Livre, Auteur, Editeur, ISBN comme des objets et non comme des tables ou des attributs de base de données. Je pense que c'est ainsi qu'il faut procéder. Ceci étant dit, admettons que les générateurs de code permettent de gagner beaucoup de temps, et qu'ils nécessitent une base de données relationnelle afin de générer le modèle et de le faire correspondre aux objets de la base de données. Je pense que c'est la raison principale pour laquelle les développeurs ont tendance à commencer par le D.B. Ce qui pourrait prouver davantage mon point de vue est que les développeurs de générateurs de code s'efforcent d'inverser le fonctionnement actuellement mis en œuvre (c'est-à-dire que vous fournissez un modèle d'entreprise - objets et classes - et le générateur crée la base de données avec le schéma approprié pour cela).

Edit :
Voici un exemple de générateurs domain-first (ADO.NET Entity Framework lui-même) Modèle d'abord :

Visual Studio 2010 a la capacité de générer une DDL et de créer une base de données pour stocker le modèle de données de l'entité. Le développeur a un contrôle total sur l'ensemble du processus, car il peut personnaliser la DDL, sélectionner la base de données de son choix ou affiner le processus de mappage.

Answer 2

Pourquoi pas l'interface d'abord ?

Trop d'applications commencent avec une mentalité de programme en premier. C'est une mauvaise idée. La programmation est le composant le plus lourd de la construction d'une application, ce qui signifie qu'elle est la plus coûteuse et la plus difficile à modifier. Commencez plutôt par la conception.

Le design est relativement léger. Un croquis sur papier est bon marché et facile à modifier. Les conceptions html sont encore relativement simples à modifier (ou à jeter). Ce n'est pas le cas de la programmation. Concevoir d'abord vous permet de rester flexible. Programmer d'abord vous enferme et vous expose à des coûts supplémentaires.

Cela vient de Chapitre 9 de Devenir réel par 37signals.

Answer 3

"Montrez-moi vos organigrammes et cachez vos tableaux, et je continuerai à être mystifié. Montrez-moi vos tableaux, et je n'aurai généralement pas besoin de vos organigrammes ; ils seront évidents."

- Fred Brooks dans "Le mois de l'homme mythique".

Answer 4

À mon avis, il n'y a pas de réponse correcte à cette question. Je pense que cela se résume principalement à vos préférences personnelles ou à celles de votre équipe. Toutes les approches mentionnées (base de données en premier, code en premier, interface en premier) ont leurs propres avantages et inconvénients.

Je m'assiérais probablement avec un stylo et du papier pour esquisser la structure générale et les principales fonctions de l'application avant de faire quoi que ce soit de spécifique, que ce soit du code ou des tables de base de données. Un simple dessin de l'interface utilisateur de base est également très utile.

Answer 5

Une analyse des besoins d'abord, puis une documentation de ces besoins et un aperçu des aspects liés aux données ?

Vous savez alors quelles données vous allez capturer et comment elles sont liées à d'autres données, et vous pouvez concevoir un schéma de base de données ou une structure de données pour y correspondre (en tant qu'objets/tables logiques de contenu lié, et non pas "tab1_data", "tab2_data" correspondant au processus de capture des données qui pourrait changer, mais vous le savez !) Vous pouvez même commencer par concevoir un fichier .xsd et générer du code et un schéma de base de données à partir de celui-ci. Tout est possible de nos jours, en fonction de vos compétences.

Étant donné que, dans mon esprit, le schéma de la base de données stocke les données et qu'il s'agit de l'élément le plus important pour une entreprise, c'est lui que je concevrais en premier - plusieurs outils pourront y accéder à terme, et le système d'origine sera peut-être remplacé par la suite (par exemple, en cas de migration vers des outils/langues/interfaces plus récents). Si vous ne connaissez rien à la théorie des bases de données, ce n'est peut-être pas votre meilleure option, mais je ferais quand même vérifier par quelqu'un d'autre tout schéma généré.