À la pointe : générer un historique CRUD

Par Dino Esposito | Mai 2016

Dino Esposito Bases de données relationnelles autour depuis les années 1970 et ont démarrent et la fin de leur carrière sans formation ou juste un peu vous envisagez une approche alternative au stockage des données de plusieurs générations de développeurs. Récemment, grands réseaux sociaux fourni des preuves que des bases de données relationnelles n'a pas pu répondre à tous les scénarios possibles pour l'entreprise. Lorsque (réellement) énormément de données sans schéma survient, les bases de données relationnelles peuvent parfois être un goulot d'étranglement plutôt qu'un canal.

Imaginez qu'il faudra compter instantanément le modèle sur un amis de commentaire à un billet dans un ensemble complète base de données relationnelle avec quelques milliards d'enregistrements total ? Afin de ne pas indiquer que la restriction de la définition de la publication à un schéma rigid est moins difficile. Pour une simple question de survie de l'entreprise, à un moment donné, les réseaux sociaux évolué et déplacées de leurs activités de stockage à une combinaison des magasins de données relationnelles et non relationnelles, officiellement en ouvrant donc l'entreprise de données POLYGLOTTE.

La leçon fondamentale de l'architecture logicielle de réseaux sociaux est parfois simple stockage de données que vous possédez pas, business-wise, l'approche idéale. Au lieu de simplement stocker toutes les données que vous avez, il est préférable de stocker des informations sur une occurrence de l'événement et les données impliquées avec cet événement particulier.

Dans cet article, je me pencherai tout d'abord à la base de professionnels de l'approvisionnement de l'événement, à l'aide des événements enregistrés en tant que source de données principale d'applications, puis décrivez comment actualiser existante création, lecture, mise à jour, des compétences de suppression (CRUD) au vu des événements. Afin de pouvoir effacer dès le début, la question n'est pas si vous avez besoin d'approvisionnement événement. La question est lorsque vous en avez besoin et comment vous le code.

Vers des modèles de données dynamiques

À l'aide des données POLYGLOTTE est un sujet d'actualité aujourd'hui : graphiquement des bases de données relationnelles pour les données structurées, magasins de données NoSQL pour les données moins structurée, des dictionnaires de clé-valeur des préférences et des journaux, des bases de données pour les relations et les corrélations. Présentation des modèles de stockage différent en cours d'exécution côte à côte est une étape dans la bonne direction, mais il me semble plus comme un recours efficace à un symptôme visible à la prévention à la maladie sous-jacent et réelle.

Le modèle relationnel doit son efficacité remonte à un jeu d'équilibrage des avantages qu'elle offre pour lire et écrire des données. Un modèle relationnel est facile d'interroger et mettre à jour même si elle indique les limites sous certaines conditions extrêmes (très). Global compréhensible diminution des performances sur les tables avec quelques millions d'enregistrements et les colonnes quelques centaines. En outre, le schéma de données est fixe et connaissance de la structure de base de données est requise pour créer des requêtes ad hoc et rapides. En d'autres termes, dans le monde vous codez aujourd'hui, un modèle complet, comme le modèle relationnel initiaux volumineux, est contrainte énorme tout d'abord finit par limiter votre expressivité et versions ultérieures, votre puissance de programmation. Au final, un modèle est un modèle et il n'est pas ce que vous observez directement dans le monde réel. Dans le monde réel, vous n'observez n'importe quel modèle. Au lieu de cela, vous utilisez un modèle pour encapsuler un comportement bien connue et reproductible. Au final, dans le monde réel, vous observez les événements mais vous attendre à stocker les informations relatives aux événements dans un modèle (relationnel) contraint. Lorsque cela s'avère difficile, recherchez dans les modèles de stockage alternatif version simplement des schémas et indexation des contraintes.

Un modèle de stockage basé sur des événements

Des dizaines d'années, il a été utile et puissante pour enregistrer uniquement l'état actuel d'entités. Lorsque vous enregistrez un état donné, vous remplacez l'état existant, donc perdre les informations précédentes. Ce comportement ne mérite éloge ou en voudrais proprement dite. Pendant des années, il s'est avéré pour être une approche efficace et acquise large acceptation. Le domaine d'entreprise et les clients peuvent préciser si la perte de l'ancien état est acceptable. Faits de dire que de nombreuses années et pour la plupart des entreprises, il était acceptable. Cette tendance change à mesure que des applications d'entreprise requièrent le suivi de l'historique complet des entités métier. Ce qui était appelé CRUD depuis des années, plain création, lecture, mise à jour, les opérations de suppression — et modélisée sur brut des tables relationnelles est maintenant en cours d'élaboration ce qui peut être générique appelé CRUD historique. Historique CRUD est simplement un code CRUD base où l'implémentation gère dépister l'intégralité de la liste des modifications.

Le monde réel est plein de systèmes de métier (LoB) qui, d'une certaine façon, le suivi des événements qu'ils se produisent dans le domaine. Ces classes d'application existent depuis des décennies, certains encore écrite en COBOL ou Visual Basic 6. Sans aucun doute, par exemple, qu'une application de comptabilité effectue le suivi de toutes les modifications qui peuvent se produire pour les factures tels qu'un changement de date ou l'adresse, l'émission d'une note de crédit et autres. Dans certains scénarios d'entreprise, les événements de suivi a été une fonctionnalité demandée depuis les débuts de logiciels, souvent entrant dans le cadre de la fonctionnalité d'audit plus large.

Par conséquent, l'audit des événements commerciaux n'est pas un nouveau concept de logiciel. Depuis des décennies, les équipes de développement résolu maintes et maintes fois, le même problème repensant et aborderont techniques connus la meilleure façon de que retrouver éventuellement. Aujourd'hui, l'ancienne bonne pratique de l'audit des événements métier passe sous le nom de source d'événement plus attrayant.

Codage permet d'événements commerciaux

Par exemple, nous supposons que vous avez une application sur le plan conceptuel simple comme celle qui permet aux utilisateurs de réserver une ressource partagée, une salle de réunion. Lorsque l'utilisateur passe en revue l'état d'une réservation donnée, elle peut s'afficher non seulement l'état actuel de la réservation, mais la liste complète des mises à jour depuis la création. Figure 1 décrit une possible basé sur la chronologie l'interface utilisateur pour l'affichage.

Figure 1 basée sur la chronologie de vue pour toute l'histoire d'une réservation

Comment vous concevez un modèle de données de réservation qui se comporte comme un historique CRUD plutôt que comme un simple CRUD basée sur l'état ? Ajoutez des colonnes à la définition de table n'est pas suffisante. La principale différence entre un CRUD et un historique CRUD est que dans ce dernier scénario, vous souhaitez stocker plusieurs copies d'une même entité, une par chaque événement commercial qui aboutir à un moment donné. Figure 2 présente une nouvelle structure possible pour la table de réservation de la base de données relationnelle.

Figure 2 un Possible modèle relationnel pour une Application CRUD historiques

Le tableau illustré Figure 2 possède le jeu de colonnes qui représentent entièrement l'état d'une entité commerciale, ainsi que quelques autres attendu. Au minimum, vous souhaitez disposer d'une colonne de clé primaire pour identifier de manière unique une ligne dans la table. Ensuite, vous souhaitez avoir une colonne horodatage qui indique l'heure de l'opération sur la base de données ou à n'importe quel horodateur qui s'avère pertinent pour l'entreprise. Plus généralement, la colonne joue le rôle d'association d'une date sans échec à l'état de l'entité. Enfin, vous souhaitez avoir une colonne qui décrit l'événement qui a été enregistré.

Il s'agit toujours d'une table relationnelle et il gère toujours la liste des réservations les besoins de l'application. Aucune nouvelle technologie a été ajouté, mais sur le plan conceptuel la table schématisé dans Figure 2 est un saut QUANTIQUE dans un CRUD classique. Il est facile d'ajouter des enregistrements à la nouvelle table. Vous venez de remplissez les enregistrements et les ajoutez que vous obtenez la notification que quelque chose s'est produit dans le système qui doit être suivi vers le bas. Beaucoup pour le C de CRUD ; mais qu'en est-il des autres opérations ?

Met à jour et des suppressions dans un historique CRUD

Une fois la table relationnelle classique a été activée dans une table d'historique, basée sur des événements, rôle et la pertinence des mises à jour et suppressions changent de façon significative. Tout d'abord, les mises à jour disparaissent. Les mises à jour à l'état de l'entité logique sont désormais implémentés en tant qu'un nouvel enregistrement ajouté qui assure le suivi de l'état nouveau.

Suppressions sont un point plus compliqué et le nec plus ultra comment coder réside dans la logique métier du domaine. Dans un monde idéal basée sur des événements, il n'existe aucune suppression. Données ajoute simplement, par conséquent une suppression est simplement l'ajout d'un nouvel événement qui vous informe que l'entité n'existe logiquement plus. Toutefois, la suppression physique des données à partir d'une table n'est pas interdite par la loi et peut toujours se produire. Notez, cependant, que dans un scénario basé sur un événement, l'entité à supprimer n'est pas constituée d'un seul enregistrement, mais se compose d'un ensemble d'enregistrements, comme représenté dans Figure 2. Si vous décidez de supprimer une entité, vous devez supprimer tous les événements (et enregistrements) qui se rapportent à elle.

Lecture de l'état d'une entité

Le principal avantage que les avantages de l'enregistrement des événements métier dans votre application est que vous oubliez jamais rien. Vous pouvez éventuellement effectuer le suivi de l'état du système à un moment donné, déterminer l'ordre exact des actions qui ont conduit à un état donné et d'annulation — en tout ou en partie, ces événements. Cela sert pour automatique faite analyse décisionnelle et les scénarios de simulation dans l'analyse de l'entreprise. Pour être plus précis, vous n'obtenez automatiquement ces fonctionnalités prêtes à l'emploi avec votre application, mais vous avez déjà des données que vous avez besoin pour développer ces extensions par-dessus l'application existante.

Lisant les données les plus difficiles d'un historique CRUD. Vous suivez maintenant tous les événements pertinents de l'entreprise dans le système de réservation d'exemple, mais il est sans emplacements où vous pouvez facilement obtenir la liste complète des réservations de capacité. Il n'existe aucun moyen de connaître, disons, le nombre de réservations, vous devez la semaine prochaine rapide et simple. Cela est où des projections. Figure 3 résume l'architecture globale d'un système qui évolue à partir d'un simple CRUD pour un historique CRUD.

Figure 3 Architecture d'un système d'historique CRUD

Un système basé sur des événements est inévitablement destiné à l'implémentation d'une séparation franche entre la pile de commande et de la requête. À partir de la couche de présentation, l'utilisateur déclenche une tâche qui passe par l'application et la couche domaine impliquant tous les composants de logique métier sur la façon dont. Une commande est le déclencheur de tâche métier qui modifie l'état actuel du système, ce qui signifie que quelque chose doit être validée logiquement modifie l'état existant. Comme mentionné, dans un système basé sur les événements, même lorsque le système est un simple système CRUD simple : modification de l'état signifie l'ajout d'un enregistrement qui indique que les utilisateurs créés ou mis à jour d'une réservation spécifique. Le bloc dans Figure 3 étiqueté les n'importe quelle couche de code « Événement référentiel » représente responsable de la persistance de l'événement. En termes de technologies concrètes, le bloc de référentiel de l'événement peut être une classe de référentiel basé sur Entity Framework, ainsi que d'un wrapper autour d'une base de données de documents (Azure DocumentDB, RavenDB ou MongoDB). Encore plus intéressant, il peut être une classe wrapper à l'aide de l'API d'un récepteur d'événements tels que EventStore ou NEventStore.

Dans une architecture basée sur des événements, l'état d'une entité donnée est calculée par algorithme à la demande. Ce processus sous le nom de la relecture d'événements et se compose d'interrogation de tous les événements liés à l'entité spécifiée et toutes les appliquer à une nouvelle instance de la classe d'entité immédiate. À la fin de la boucle, l'instance d'entité est à jour, car il a l'état d'une nouvelle instance arrivé à tous les événements enregistrés.

Plus en général, le journal des événements de traitement crée une projection des données et extrait un modèle de données dynamique hors d'une quantité de bas niveau de données. C'est ce qui est appelé le modèle de lecture dans Figure 3. Sur le même journal des événements, vous pouvez créer tous les modèles de données qui desservent les diverses applications frontales. Pour utiliser une analogie SQL, création d'une projection des données d'événements enregistrés est identique à la création d'une vue d'une table relationnelle.

Relecture d'événements pour déterminer l'état actuel d'une entité à des fins de requête est généralement une option viable, mais il devient de moins en moins efficace que le nombre d'événements ou la fréquence des requêtes augmente au fil du temps. Vous ne souhaitez pas passer par plusieurs milliers d'enregistrements chaque fois simplement pour vérifier le solde actuel d'un compte bancaire. De même, vous ne souhaitez pas parcourir des centaines d'événements pour présenter la liste d'attente de réservations. Pour résoudre ces problèmes, le modèle de lecture prend souvent la forme d'une table relationnelle classique qui est par programmation reste synchronisée avec la table des événements enregistrés.

Synthèse

La plupart des applications peuvent toujours être catalogué manifestement en tant qu'applications CRUD. La même façon Facebook peut être présenté de manière sous un CRUD, peut-être un peu supérieure à la moyenne. Sérieusement, pour la plupart des utilisateurs le dernier état correct connu est toujours insuffisant, mais augmente le nombre de clients pour lequel cette vue est insuffisante. L'autre peut être simplement votre meilleur client. Cet article aborder tout simplement d'un historique CRUD. Le mois prochain, je vais présenter un exemple concret. Restez connecté.

Dino Espositoest l'auteur de « Microsoft .NET : Conception d'Applications pour l'entreprise » (Microsoft Press, 2014) et « Applications Web modernes avec ASP.NET » (Microsoft Press, 2016). Un développeur technique pour les plateformes .NET et Android chez JetBrains, dans le monde entier manifestations du secteur, Esposito partage sa vision du logiciel à software2cents.wordpress.com et sur Twitter : @despos.

Merci à l'experte technique Microsoft suivante d'avoir relu cet article : Jon Arne Saeteras