Discussion :

[JMLJ]

Bonjour tous le monde,

voila j'ai une petite question sur l'architecture d'une application.

Dans la société où je travaille, nous développons une application en .Net client lourd (Windows Form). C'est une Gestion Interne qui permet de suivre les clients de la prise de commande à la facturation en suivant ensuite les comptes clients pour affecter les réglements, impayés, agios, etc ... Classique quoi

Nous sommes en plein developpement et nous nous sommes reposé sur architecture en 5 couches : IHM, Application, Metier, Mapping et Persistence.

Voila ma question (enfin !!! ) :

Si demain je décide de traiter la partie IHM en WebForm avec ASP.Net, est-ce que cela peut impacter tout le travail fait côté Métier ?

C'est à dire par exemple actuellement quand je désire obtenir une liste de Facture, mes objets "métiers" sont instanciés en mémoire sur le poste client. Mais si je fais du client léger, comment ça se passera ? Mes objets en mémoire le seront cette fois sur le serveur de page ? Si c'est le cas, il faut peut-être justement limiter la création de listes d'objets qui demanderont autant de mémoire qu'il y a de clients connectés

Je n'ai pas encore réellement developpé d'application en ASP.Net mais je me suis arrêté sur la théorie que l'on pouvait avoir un tronc commun pour une application Web et Win32 ...

Je délire ou c'est jouable ???

Merci

[Royd938]

Tu ne délires pas...c'est tout le problème du choix entre le lazy loading et l'agressive loading. Tout dépend un petit peu de la quantité d'objet à créer. Le lazy loading est à mon avis le plus souvent utilisé...

[man_in_the_cube]

Bonjour,
En voyant plus loin que le "simple" problème de lazy loading....
cette histoire de tronc commun tu dois revenir sur le sens de l'architecture en couche.
- Mes couches ont t'elles assez d'indépendances ?
- Quellles sont les infos qui devrons transiter entre les couches
et necessairement quelle format ...voir de protocol...car c'est bien de cela qu'il s'agit en vérité.

Car avant de se demander "lazy" ou pas "lazy", il est nécessaire de déterminer quel est le parcourt de ton information (tu peu parler de flux) au travers des couches et surtout quelles transformations elle subira avant son utilisation effective.

Une fois que tu sais cela , le reste vient tout seul


bye.

[JMLJ]

D'abord merci Royd938 pour cet aspect intéressant ;-)

> Quellles sont les infos qui devrons transiter entre les couches
> et necessairement quelle format ...voir de protocol...car c'est bien de
> cela qu'il s'agit en vérité.

> Car avant de se demander "lazy" ou pas "lazy", il est nécessaire de
> déterminer quel est le parcourt de ton information (tu peu parler de
> flux) au travers des couches et surtout quelles transformations elle
> subira avant son utilisation effective.

Bah c'est là le probléme, je ne maitrise pas vraiment ce qui transite !!!!
J'ai fait une petite maquette ou j'ai bien dissocier les différentes couches dans différentes assembly (je fais du .Net je le rappel ;-) ).

Donc sur une application Client/Serveur mes DLL sont sur mon poste client. Et ce qui transite dans le tuyau ce sont les données provenant du SGBD. Mais en ASP.Net tout est sur le serveur j'imagine. Il transite donc sur le réseau (entre le Browser et le serveur d'application) juste la page à afficher. Par contre sur ce serveur il y a une réservation en mémoire des objets qui ont servis à la composition de ma page. Ce que je veux savoir c'est qu'est ce qui me limite au point de vue espace mémoire dans une telle architecture. Mais peut-être que je n'ai pas bien compris la mécanique et c'est pourquoi je suis peut-être en train de poser une question idiote

Merci de faire avance mon schmilblik

JMLJ

[JMLJ]

Je me réponds, c'est plus rapide

Vous me confirmerez mais puisque je crée en ASP.Net mes pages sur le serveur (qui seront ensuite envoyées au client), a moi de libérer les objets que j'ai instancié sur mes couches métier. C'est vrai qu'à la différence d'une appli Client/Serveur en ASP.Net je suis en mode déconnecté. Donc si je modifie des enregistrements d'une table par exemple, il faudra faire un update et eventuellement remonter une exception (concurence d'accés par exemple). En mode Client/Serveur je gardais mes objets metiers en mémoire dans le but de les verrouiller à des accés concurentiels ;-)

Mon architecture me permet cela, donc ok j'ai compris le binz ;-)))

Merci 8)