Toutes les suggestions pour séparer l'accès aux données, la logique métier et l'interface graphique dans Delphi

Question

Je souhaite séparer la couche de données de la logique métier et de la logique métier de l'interface graphique. Plonger dans le web Je suis tombé sur quelques ressources mais toujours incapable de me faire comprendre. Certaines personnes parlent de modèles tandis que d'autres pointent différents cadres. Mes exigences sont les suivantes:

• manipuler les données de SGBDR (MySQL principalement) opérations CRUD
• concernant la production d'id (dois-je utiliser autoincrement ou moteur de données fourni ou un code pascals généré)
• relations de table peut être logique (pas d'intégrité référentielle est utilisé) ou non
• besoin de capacité de générer des relations d'objet à partir du modèle de données
• données doivent être converties en objet métier et la logique métier manipulé
• composants graphiques existants ou les freeware devraient être utilisés

Ce que j'ai besoin est:

• certaines techniques/suggestions de guidage avec le code/mise en page d'application échantillon de base (tels que les unités-classes-modules-répertoires) ... Etre pas un expert en POO-je obtenir confus quand je dois concevoir la hiérarchie des classes
• un cadre simple avec un tutoriel
• ou même votre propre code quotidien/cadre/approche

Answer 1

Mettez vos mains sur l'open source InstantObjects et vous voudrez toujours l'utiliser pour toutes sortes de programmation de base de données en Delphi.

Dans IO, vous devrez définir l'ensemble de la structure de données dans son interface et ensuite générer le code nécessaire pour vous.

Essayez-le. En ce qui concerne la génération d'ID, faites confiance à MySQL pour générer un ID d'incrémentation automatique pour votre. Ne passez pas le temps à le coder.

Answer 2

Puisque vous utilisez Delphi, assurez-vous de consulter DataModules. C'est ici que vous placez vos composants et votre logique d'accès à la base de données.

Placez les classes dans des fichiers "Unit" simples.

Faites en sorte que l'interface utilisateur communique avec ces deux éléments pour que les choses se passent bien. Vous pouvez utiliser les composants d'accès à la base de données directement sur le formulaire, mais il est préférable de le faire en mode "affichage uniquement" et d'utiliser le module de données pour effectuer les opérations sur les données. (Vous pouvez tout faire sur le formulaire pour les applications de base, mais si vous voulez moduler l'application, il est judicieux de la garder à l'écart).

Answer 3

Un moyen simple d'aider à imposer ce type de séparation consiste à écrire des tests unitaires pour votre logique métier. Mis à part les autres avantages (substantiels), rendre le code testable signifie qu'il ne peut pas (intentionnellement ou autrement) être étroitement couplé à l'interface utilisateur. J'essaie de (mais ne réussis pas toujours) de séparer les détails de la couche de données en utilisant ClientDataSets indépendamment de ce qui est utilisé dans le backend (généralement DBExpress ou DBISAM). J'essaie également d'écrire au moins quelques tests d'intégration pour m'assurer que la couche de données fonctionne comme prévu (base de données de test séparée avec des valeurs connues).

Avec la logique métier et les données en place (même partiellement), l'interface utilisateur est beaucoup plus simple. Et maintenable.

Answer 4

Une méthode que j'utilise, et qui fonctionne très bien, consiste à essayer d'effectuer différents lancements à partir de votre application, puis de programmer comme si vous étiez dans ce rôle. Par exemple, lorsque vous travaillez sur la base de données back-end, ne pensez même pas à l'interface graphique. Pensez plutôt à exposer des classes et des méthodes qui fonctionnent uniquement avec les données. Si vous faites votre propre SDK que vous consommerez plus tard, vous constaterez que la maintenance de ce sera beaucoup plus facile.

Le développement basé sur les tests est votre ami. Apprenez à connaître DUnit et créez de petits tests concis pour exercer n'importe quel code non trivial. Documentez les interfaces, et tout ce qui n'est pas apparent en regardant un écran plein de code.

Answer 5

Jetez un oeil à tiOPF

Answer 6

Personnellement, j'utilise tiopf pour le modèle d'affaires. Tiopf fournit la couche d'accès aux données. Le dernier code du référentiel inclut un framework model-gui-mediator similaire à MVC pour l'affichage du modèle. Cela vous permet d'afficher vos données en utilisant des composants Delphi standard.

Tiopf comprend également un certain nombre de générateurs d'ID (guids, entiers 32 bits et 64 bits, etc.).

Si vous êtes intéressé par tiopf, je vous suggère de commencer par regarder mon overview. Ensuite, adressez vos questions aux groupes de discussion.

Answer 7

Je regarderais Model-View-Controller (qui est une extension du modèle Observateur/Observable). Cela signifie que la 'vue' (c'est-à-dire l'interface utilisateur) ne sait comment mettre à jour les données et répondre ensuite aux données mises à jour. Le modèle (ou observable) sait comment manipuler les données et indique aux vues qu'elles ont été mises à jour. Cela signifie que vous pouvez remplacer l'interface utilisateur sans avoir à modifier le fournisseur de données et vice-versa.

Faites une recherche sur Google, car il y a beaucoup d'exemples de cela pour Delphi (mais pas autant pour Java/C#, etc.)