Discussion :

[rdmontreal]

Question existentielle:

Quelles sont les différences entre créer des classes avec héritage/modèle/vue et quelles sont les meilleures pratiques dans un contexte de maintenance à long terme? (Et je mets de côté les possibilités de rendre une classe abstraite, ou de l'importer d'un autre projet... Sans oublier les structures d'attributs ou la possibilité de joindre deux tables de la bd dans une classe... Je vous ai mentionné les relations de composition?).

Et la question à 1000$: Comment cela affecte la performance de l'appli? Ici, je peux avoir des 100 000 de données.

Ça va pour le concept d'héritage, si on a une pensée "java".
Une "vue" sur une classe, alors c'est comme une VIEW en SQL?
Que vient faire le modèle (template)?

J'ai un cas concret et très classique à réaliser : j'ai un modèle de données PERSONNE qui peut être un EMPLOYÉ, CLIENT, CONTACT etc. Un EMPLOYÉ peut être DIRECTEUR, REPRÉSENTANT etc. Jusqu'ici, j'ai pris une approche de relation avec composition mais ça me semble lourd et ça devient compliqué si je veux filtrer à des niveaux supérieurs. Et j'ai des infos que je n'ai pas besoin à des niveaux inférieurs.

Au Québec, on dit que c'est une discussion à avoir en buvant une bière...

[Nico02]

Question existentielle:
Quelles sont les différences entre créer des classes avec héritage/modèle/vue et quelles sont les meilleures pratiques dans un contexte de maintenance à long terme?

Ce sont tous des concepts différents, donc il n'y a pas vraiment de réponse à ta question (qui n'a d'ailleurs pas vraiment de sens). Si tu as besois de faire de l'héritage et bien tu en fait. Sil il te faut des vues, tu va les créer. Il n'y a pas de "mieux" ou "moins bien", ça dépend de ce que tu veux/dois faire.

Et la question à 1000$: Comment cela affecte la performance de l'appli? Ici, je peux avoir des 100 000 de données.

La performance d'une application ne se mesure pas avec des concepts.

C'est simplement la maitrise de toute ces choses qui va faire qu'une application est performante ou non. Tu peux très bien faire des choses qui marchent très bien avec peu de moyen. A l'inverse, tu peux aussi faire planter le plus gros des PC avec une requête SQL mal construite..

[rdmontreal]

Petit rappel: la question est posée dans le contexte Business First - Application Composer et Application Engine.

Pour ce qui est de la performance, il faut comprendre comment l'App Eng gère ses objets. Si j'ai 10 000 "personnes" dans ma bd, est-ce qu'App Eng va instancier 10K objets PERSONNE et 10k EMPLOYE si j'utilise un héritage/modèle etc. Si j'ouvre deux formulaire PERSONNE et EMPLOYE, est-ce que les objets communs sont partagés/référés? Comment les notifications JMS, les actions imports/exports sont affectées? etc. Concrètement, j'ai des cas où un formulaire prend +20 secondes à s'afficher ça n'a rien à voir avec SQL, le serveur ou le poste de travail. Et c'est avec des données de test qui représentent moins de 10% du volume réel.

Il y a probablement des "bonnes" ou "mauvaises" pratiques. Je ne peux que faire des suppositions. Mais peut-être que des développeurs BF ont de l'expérience et peuvent partager leur vécu et leurs préférences.

Praticiens, exprimez-vous!

[rdmontreal]

Exemple de vécu:
Le manuel utilisateur de BF indique comment créer une vue en moins de 20 lignes. Donc, rien de particulier à noter.

Alors je crée une vue, j'ajoute une relation de composition pour un besoin spécifique. App Composer le permet.

Quand je lance l'appli:
[FATAL] BF AppEngine : Application can't start, BF AppEngine : a F_BIND_INFO must be used for STORMClassPartyCustomerViewRelationCustomer (because it belongs to class info STORMClassPartyCustomerView that has a C_BIND_INFO)

Alors on cherche une autre approche. Et on recommence. Ma solution temporaire: créer toute les relations dans la classe mère, les cacher... Ça me semble un détour.