L'utilisation de composants sensibles aux données Delphi - pour et le contre [fermé]

Question

Je veux connaître votre opinion sur l'utilisation de composants de données dans les projets. Quelles sont les points « force » et « faibles » de développement d'applications (win32 et web), en utilisant des composants Delphi et sensibles aux données (de suite standard de Delphi ou tiers)?

Utilisation FireBird Je travaille beaucoup avec IBObjects, qui sont une suite de composants matures et fonctionnait très bien.

Mais il y a aussi beaucoup d'autres SGBDR (MySQL, MSSQL, DB2, Oracle, SQLite, Nexus, Paradox, Interbase, FireBird etc). Si vous avez développé de grands projets sur lesquels vous avez utilisé un composants de données du lot Veuillez répondre avec le type de base de données et composants nom de la suite de données SENSIBLE.

Je suis également intéressé sur DB2 (AS400). Quels composants avez-vous utilisé avec succès, ou quels composants sont vraiment une douleur à travailler?

Answer 1

J'ai trouvé que l'utilisation des composants de données des résultats dans une application sans distinction claire entre les entreprises et la logique interface utilisateur.

est très bien pour les petits projets mais comme ils grossissent le code devient de moins en moins maintenable.

Tous les différents bits de code d'événement (et leurs interactions) peut devenir un véritable cauchemar pour comprendre!

Invariablement dans de tels cas, j'ai composants abandonné sensibles aux données et sont passés à une conception MVC (code à la main).

Cela exige beaucoup d'efforts de codage à l'avance, mais les résultats (IMHO) dans un projet qui est maintenable, extensible et débogable.

Answer 2

Après avoir essayé les deux données sensibles au style et non sensibles aux données des applications Delphi je suis de retour dans le camp de composants au courant des données ces jours-ci. Il faut un peu à la couche correctement de travail et la discipline du code, mais il est encore plus rapide que de faire tout à la main en utilisant des contrôles non sensibles aux données.

Quelques conseils de mes pour l'utilisation des données composant SENSIBLE sont

• Ne vous contentez pas récrire FishFact à plus grande échelle. Mettez un peu de pensée dans votre conception.

• Ne pas utiliser TDataModule, utilisez beaucoup TDataModules chacun représentant un petit aspect de vos données d'applications.

• TDatasets appartiennent à TDataModules, tandis que TDataSources appartiennent à TForms (à moins utilisé pour les relations maître / détail).

• Utilisation des jeux de données en mémoire, tels que la DataSnap TClientDataSet.

• Vos ClientDataSets ne pas refléter vos tables de base de données exactement. DataSnap vous permet de masser vos structures de données en mémoire afin que vous puissiez produire des ensembles de données adaptés à des fins spécifiques. Plus précisément, vous pouvez faire des choses comme

  • Joindre deux ou plusieurs tables dans le jeu de données modifiable d'un

  • Dénormaliser structures de table de détail de maître, peut simplifier votre code d'interface utilisateur parfois.

  • Créer uniquement en mémoire des champs (comme des champs calculés, mais vous pouvez les écrire aussi)

• TClientDataset tables imbriquées sont utiles, mais pas la seule façon d'exprimer les relations maître détail. Parfois, il est préférable de le faire à l'ancienne avec deux TClientDataSets indépendants reliés par un TDataSource.

Answer 3

Jetez un oeil à des solutions ORM.

Il est une approche agréable avec une architecture à plusieurs niveaux. Voir ORM pour DELPHI win32

Answer 4

Les données sont au courant des contrôles très bien, mais vous devez vous assurer d'obtenir votre code d'entreprise dans une couche séparée.

Ce n'est pas difficile, mais vous devez savoir sur la façon dont vous pouvez le faire.

Une approche est d'avoir vos composants DataSet dans un module de données (ou un autre récipient non visuel).

Une autre astuce pratique consiste à utiliser un TClientDataSet pour faire l'entrée de l'interface utilisateur, et l'utiliser comme un tampon intermédiaire entre l'interface utilisateur et la couche d'affaires. La couche métier utilise ensuite des composants TDataSet spécifiques à votre couche de données.

- jeroen

Answer 5

données SENSIBLE Delphi composants ne sont pas dépendent du moteur de base de données back-end que vous utilisez, donc en utilisant Firebird ou MS SQL Server ou Oracle ou d'autres n'a pas d'importance à vos composants de données SENSIBLE. Ils ne connaissent que le composant source de données qui leur sont assignées et font toutes leurs affaires connexes DB par cela.

Pour moi, si quelque chose peut être fait avec des composants de données SENSIBLE d'une manière agréable, je vais les utiliser. Ce sont généralement de petits projets qui devrait être fait dans un court temps. Dans de plus grands projets, je pourrais exclure totalement composants de données ou de les utiliser dans des formes qui sont simplement utilisées pour la présentation des données et ne reçoivent pas l'entrée d'utilisateur. Quand il vient de recevoir l'entrée d'utilisateur, je pourrais utiliser des composants non sensibles aux données parce que j'ai plus de flexibilité pour les contrôler et valider l'entrée. Des composants bien sûr des données-ware peuvent encore être utiles dans de tels scénarios aussi. Vous pouvez toujours valider les entrées utilisateur dans les données des événements comme OnBeforePost. Aussi, si vous utilisez un modèle à plusieurs niveaux, et votre application client REPRÉSENTE données couche de présentateur, la validation de votre entrée se fait au niveau intermédiaire afin que vous puissiez recevoir des commentaires en utilisant des composants de données SENSIBLE dans l'application client, et les envoyer à la de niveau intermédiaire pour la validation et le traitement ultérieur.

Answer 6

Composants de données-aware sont usful du point de vue RAD et le prototypage, surtout quand vous êtes des rapports de conception ou de grilles qui reposent sur des données. à-dire que vous pouvez bricoler au moment de la conception. Donc, je les utilise comme ça. Mais quand vient le temps de le transformer en code de navigation, je presque toujours couper les connexions, retirez le SQL des requêtes, et tout faire dans le code. Il est beaucoup plus prévisible et maintenable cette façon, en particulier dans un environnement multi-développeur avec contrôle de version. Lorsque le SQL est intégré sous la forme quelque part, c'est une grande douleur pour essayer de savoir où le SQL réside effectivement. Et il est particulièrement mauvais d'avoir SQL en deux endroits, et d'avoir à comprendre ce qui est en vigueur.

Answer 7

Vous pouvez utiliser UniDAC qui prend en charge de nombreux serveurs de bases de données, y compris Firebird (que je l'utilise) et caractéristiques très agréable.

Remobject SDK vous aurez une combinaison agréable de l'architecture n-tiers et l'abstraction de base de données.