Discussion :

[billou77]

Bonjour,

j'ai telechargé cette nuit XMLRAD 2005.

La doc en ligne me convient (elle est suffisamment détaillée). Par contre, je n'arrive pas à mettre la main sur des docs (des slides powerpoint ou autre) montrant les differentes couches d'une application concue via XMLRAD (IIS/XMLCLX/XSL/XML,...). Je viens du monde C#, je suis habitué à faire de l'objet et du MVC, et je souhaiterais savoir un peu où se situe le M, le V et le C dans ce XMLRAD.

Help !

[RDM]

tu as une overview de l'architecture ici:
http://xmlrad.com/DelosBin/Delos.dll/ServePage?URL=architecture.htm&WEB_ID=101001015&

concernant l'approche MVC (Model/View/Controller) on peut voir par exemple:

Model = DataSource (ou quelconques sources de données)
View = XSL
Controller = XMLGram (ou le framework XMLCLX = le moteur d'interprétation XMLGram)

Mais l'approche de XMLRAD n'est pas orienté objets (ce qui revient a faire une approche langage) mais orienté données qui est plus universel que le langage.

[billou77]

où se trouve la logique métier ? dans le xmlgram ? dans du script ? dans du code exterieur (apparemment on peut faire du delphi, java, .Net ou autre) ? la logique métier se trouve dans le M ou le C ou le V ?

donc si j'ai bien compris, je dois laisser tomber les notions objets (et mvc) pour retourner au coding en procedurale (c'est à dire ne faire que des fonctions, pas possibilité d'utiliser mes objets metier que j'aurais esquisser via mes diagrammes de classes uml) ?

ca m'inquiete un peu car ca change mes habitudes de coder... non ?

[RDM]

Les règles de de gestion se trouve dans le C.
tu as des gestionnaires d'événement pour chaque action et dans l'execution du XMLGram.
Tu peux coder effectivement en Delphi, en Scripting comme du JScript, en .NET (C#, VB.NET, J#, C++.NET, Delphi.NET, ...) ou en Java... (bientot en PHP)

oui l'approche objet avec UML et tout le tintouin ne sert a rien pour XMLRAD.
Pour faire cependant un parallèle, tu peux considérer que c'est dans le XMLGram que sont tes objets métier. Au lieu d'avoir des classes dans un certains langages, disons une classe Customer, tu as une description de la classe sous forme XML avec une requête SQL. Donc le XMLGram représente les classes métiers.
L'instance des classes métier se trouve dans le document XML résultant de l'execution du XMLGram. (OutputDoc). Tu retrouves tes objets métiers (comme Customer) avec les propriétés et valeurs à l'intérieur.
Tu peux alors dans les gestionnaires d'événements manipuler le tout comme bon te semble.

Cette approche permet d'être indépendant des langages/plateformes. La preuve on peut faire ca en dans les langages cités plus haut.
D'autre part, XMLRAD est un concentré des bonnes pratiques pour développer une application Web. Il te fournit un cadre de développement avec les bonnes méthodes de travail.
Tu obtiens donc une application qui va être optimisé au mieux et capable de montée en charge.
Tu as tous les outils et statistiques pour diagnostiquer et suivre en production l'évolution de ton application.

[billou77]

Cela commence à m'interesser, ce parallelisme entre la conception objet et la conception xmlrad. Cela me permet de mieux comprendre la philosophie xmlrad.

Donc si j'ai bien compris le xmlgram peut etre vu comme un objet metier.

Comment, sous xmlrad representait la notion d'héritage et d'association ?

On peut prendre un exemple concret, par exemple pour un site de e-commerce : un Client qui est une Personne et qui peut passer des Commandes.

En conception objet, on aurait :
- une classe Personne
- une classe Client qui herite de Personne
- une classe Commande
- la classe Client peut etre associé de 0 à N Commande(s)

On pourrait effectuer des operations sur ces classes:
- creer une Personne
- creer un Client
- creer une Commande pour un Client donné
- lister les Commandes qu'a passées un Client
- mettre à jour le nom/prenom du Client (qui sont des attributs hérités de Personne)
- modifier une Commande

Comment cette architecture objet serait traduite sous XMLRAD ? (module, service, xmlgram, ...)

Je deviens de + en + curieux :o

[RDM]

oui mais c'est là ou la différence entre ton approche objet et l'approche XMLRAD.
XMLRAD se base sur les données ! Donc sur une base de données qui elle est bien concrète et non sur une abstraction objets (qui est en fait une reformalisation dans un lagnage de ce qui est stockée dans ta base)

XMLRAD travaille directement sur les données en base. Si conception il doit y avoir c'est celle de ta base de données. Après, tout le reste viendra naturellement.

Si je reprend ton exemple:
j'ai
une table Personne
une table Client qui "hérite" de Personne (relation 1-1 entre les 2 tables)
une table Commande avec une relation sur la table Client

ensuite on va travailler avec les requêtes SQL qui vont être décrite dans le XMLGram.

Créer une Personne
XMLService InsertPersonne, dans le XMLGram: DBBatch
INSERT INTO Personne (...) VALUES (...)

Créer un client
XMLService InsertClient, dans le XMLGram: DBBatch
INSERT INTO Client (...) VALUES (...)

Créer une commande pour un client donné
XMLService InsertCommande, dans le XMLGram: DBBatch
INSERT INTO Commande (...,CLIENT_ID,) VALUES (... :CLIENT_ID)
CLIENT_ID est l'ID du client pour la commande (passé en paramètre dans le context)

Liste les commandes qu'a passé un client
XMLService ListCommande, dans le XMLGram: DBExtract
SELECT COMMANDE_ID, CLIENT_ID, ... FROM COMMANDE WHERE CLIENT_ID = :CLIENT_ID
CLIENT_ID est l'ID du client passé en paramètre dans le context

Mettre à jour le nom/prénom du Client
XMLService UpdateClient, dans le XMLGram: 2 DBBatchs
UPDATE Client
SET champs spécifique au client
WHERE CLIENT_ID = :CLIENT_ID

UPDATE Personne
SET nom = :nom,
prenom = :prenom
WHERE PERSONNE_ID = :CLIENT_ID

Modifier une commande
XMLService UpdateCommande, dans le XMLGram: DBBatch
UPDATE Commande
SET champs spécifique a Commande
WHERE COMMANDE_ID = :COMMANDE_ID


Voilà. comme tu le vois toute l"intelligence" de l'application se situe au niveau des requêtes SQL.

une fois que tu as créé tes XMLServices, tu peux les invoquer a partir d'ou tu veux en les composant.

Tes objets et ta modélisation ne servent qu'à formaliser ce que tu as dans ta base de données pour ton langage de programmation.
avec XMLRAD tu fais la même chose mais indépendemment du langage grace à la description XML (XMLGram, fichier de config XML).

[billou77]

Et ce qui suit, c'est bon ? :

Mettre à jour les données du Client
XMLService UpdateClient, dans le XMLGram: 1 DBBatch et 1 DBExtract et 1 appel à un autre service
- UPDATE Client
SET champs spécifique au client
WHERE CLIENT_ID = :CLIENT_ID

- SELECT PERSONNE_ID FROM CLIENT WHERE CLIENT_ID = :CLIENT_ID

- Appel au XMLService UpdatePersonne (on peut appeller un autre service ici alors ?)



Mettre à jour les données d'une Personne
XMLService UpdatePersonne, dans le XMLGram: 1 DBBatch
- UPDATE Personne
SET champs spécifique à la personne
WHERE PERSONNE_ID = : PERSONNE_ID


C'est mieux si l'update de la Personne se fait dans un service Personne et non dans un service Client, non ?

Du coup, si je modifie la structure de ma table Personne, je n'ai pas à modifier plein de services, mais juste UpdatePersonne, InsertPersonne, DeletePersonne, non ? (pas besoin de modifier aussi les services du client) (merci l'objet)

[RDM]

Et ce qui suit, c'est bon ? :

Mettre à jour les données du Client
XMLService UpdateClient, dans le XMLGram: 1 DBBatch et 1 DBExtract et 1 appel à un autre service
- UPDATE Client
SET champs spécifique au client
WHERE CLIENT_ID = :CLIENT_ID

- SELECT PERSONNE_ID FROM CLIENT WHERE CLIENT_ID = :CLIENT_ID

- Appel au XMLService UpdatePersonne (on peut appeller un autre service ici alors ?)

tout a fait, c'est effectivement la bonne méthode !

Mettre à jour les données d'une Personne
XMLService UpdatePersonne, dans le XMLGram: 1 DBBatch
- UPDATE Personne
SET champs spécifique à la personne
WHERE PERSONNE_ID = : PERSONNE_ID


C'est mieux si l'update de la Personne se fait dans un service Personne et non dans un service Client, non ?

Du coup, si je modifie la structure de ma table Personne, je n'ai pas à modifier plein de services, mais juste UpdatePersonne, InsertPersonne, DeletePersonne, non ? (pas besoin de modifier aussi les services du client) (merci l'objet)

oui tu as raison, il vaut mieux faire comme cela. on factorise ainsi les Services métiers pour être réutiliser a d'autre endroit.
ce n'est que de la composition finalement pour parler en terme objet.