J'écris une application, il existe différentes formes et leurs datablodules correspondantes.
J'ai écrit de manière à ce qu'ils s'en consomment en mentionnant une classe d'utilisations (une dans la mise en œuvre et une autre interface pour éviter la référence croisée)
Cette approche est-elle fausse? Pourquoi ou pourquoi je ne devrais-je pas utiliser de cette manière?
4 Réponses :
Je dois être d'accord avec Ldsandon, IMHO, c'est bien mieux d'avoir plus d'un DataModule dans votre projet. Si vous le regardez comme un modèle - Affichage - Tuske de contrôleur, votre dB est le modèle, vos formulaires seraient les vues et vos données de données seraient les contrôleurs.
Personnellement, j'ai toujours au moins 2 datamodules dans mon projet. Un datamodule est utilisé pour partager des actions, des imageurs, une dbconnection, ... et d'autres choses tout au long du projet. La plupart du temps, c'est mon point de données principale.
à partir de là, je crée une nouvelle DataModule pour chaque "entité" dans mon application. Par exemple, si mon application doit procéder ou afficher des commandes, des curseurs et des produits, je disposerai d'une source de données pour chacun de ceux-ci.
De cette façon, je peux clairement séparer la fonctionnalité et réutiliser facilement des morceaux sans avoir à tirer dans tout. Si j'ai besoin de quelque chose lié aux clients, je suis simple à utiliser les clients DataModule et juste cela.
Cordialement,
Stefaan
C'est correct, surtout si vous allez créer plusieurs instances de la même forme à l'aide d'une instance différente du DataModule associé.
Soyez juste au courant d'un petit problème dans la conception de VCL: si vous Créez deux instances de la même forme et de leurs données de données, les deux formes indiquent que le même Datamodule (due la manière dont la VLC résout les liens) à moins que vous n'utilisiez un peu d'astuce lors de la création de l'instance DataModule: P>
if FDataModule = nil then
begin
FDataModule := TMyDataModule.Create(Self);
FDataModule.Name := ''; // That will avoid pointing to the same datamodule
end;
Au-delà du verre à la recherche. J'utilise toujours des formulaires au lieu de Datamodules. Je sais que ce n'est pas un terrain d'entente.
J'utilise toujours des formulaires au lieu de Datamodules. Je les appelle Datamovules.
J'utilise un de ces données de données par groupe de tables logiquement liées.
i Utilisez des formulaires au lieu de DataModules car les données de données et les formulaires sont des conteneurs de composants et les deux peuvent être utilisées efficacement comme conteneurs pour composants liés aux données.
pendant le développement:
Après le développement:
Je fais de la forme invisible. En faisant pratiquement une source de données, j'apprécie les mêmes fonctionnalités de conteneur que celle d'une DataModule.
mais avec un bonus. La forme est toujours là, afin que je puisse éventuellement pouvoir le transformer visible pour la détermination des problèmes. J'utilise la case à propos de cela.
et non, je n'ai connu aucune pénalité notable dans la taille ou la performance de la demande.
Je n'essaie pas de casser le paradigme MVC. J'essaie de m'y adhérer à la place. Je ne mélange pas les formes qui constituent mon point de vue avec les Datamovules qui constituent mes contrôleurs. Je ne les considère pas en partie de ma vue. Ils ne seront jamais utilisés comme interface utilisateur de mon application. Datamovules vient d'être des formes. Ce ne sont que des artefacts d'ingénierie commode.
Eh bien, je suppose que vous favorisez multiple Data (m / v) ODules. ;)
Les formulaires sont "poids lourds" par rapport aux données DataModules. Parce qu'ils sont en réalité des "fenêtres", ils utilisent des ressources système, ils ont un winProc, etc., etc. DataModules sont beaucoup plus légers. Voir peu besoin de montrer un formulaire avec seulement des composants non visibles. Oui, vous pouvez imprimer une sortie de débogage, IMHO Il existe de meilleures façons d'effectuer cela.
Ouais, j'en utilise autant que je dois organiser logiquement ma demande et promouvoir la réutilisation.
J'utilise des composants visibles, généralement un datagrid par table.
+1 bien indiqué. Pas mon approche, mais intéressant néanmoins.
Un module de données uniquement pour vos objets de table, si vous n'avez que quelques tables DB, ce serait un bon pour être le premier.
et un module de données juste pour vos actions en est une autre.
Un module de données uniquement pour les listes d'images, est un autre bon module de troisième dessinateur. Ce module de données contient uniquement des listes d'images, puis vos formulaires qui nécessitent un accès aux listes d'images peuvent les utiliser à partir de cet emplacement partagé.
Si vous avez 200 objets de table, peut-être plus d'un module de données uniquement pour les tables DB. Imaginez une application contenant 20 tables à faire avec la facturation et 20 autres tables à faire avec HR. Je penserais à une facturationDataModule et à HrdataModule serait agréable d'être séparé si les tables à l'intérieur d'eux et que le code qui fonctionne contre eux, n'a rien besoin de savoir quoi que ce soit, ni même lorsqu'un module a une dépendance "utilise" Dans une direction, mais cette relation n'est pas circulaire. Même dans ce cas, une modularité de module de données grain finisse peut être bénéfique.
Vous devez ré-écrire le titre pour indiquer plus clairement la nature de votre question. Vous ne pouvez probablement pas le modifier, alors je vais le faire pour vous ....
IMO, Datamodules ne doit jamais faire référence aux formulaires du projet. Si un formulaire doit, par exemple, réagir à une modification d'un jeu de données, placez-le sur ladite forme, associez-le au jeu de données et mettez votre code dans l'événement de TdataSource.
Revenons à des questions telles que ces années plus tard, je trouve qu'il est intéressant de noter que, en l'absence de limites sur la quantité que vous pouvez pousser dans une forme, un module de données ou une unité, des développeurs Delphes en moyenne trop de choses dans un module / Unité / fichier au lieu de penser à ce qui rend le sens réel et maintenu et lisible.
Warren .. En venant à ceci après vos années, je pense que tous les développeurs doivent être mieux éduqués dans la conception de logiciels et mieux éduqués en informatique en général. Compter moi-même, il y a encore des choses que je ne sais pas que je devrais apprendre aussi bien.