Discussion :

[Bal1n]

Bonjour,

Je m'en remet à vous car je doute sur mes facultés d'analyse là ...

Nous sommes des irréductibles Gaulois (Vb6 / Asp ...) qui souhaitons évoluer vers .net

Nous souhaitons de plus faire évoluer notre méthode de conception vers une architecture n-tiers. (DAL / WLL / Presentation)

Si cette architecture semble bien assimilé au niveau des gains en terme d'efficacité de développemnt et de réutilisatibilité des objets, ca l'est beaucoup moins en ce qui concerne la mise en place technique.

- Comment partager un objet à plusieurs applications ? (l'objet de connexion au BDD par exemple)
- Comment faire dialoguer la présentation avec la couche WLL ?
- Comment faire dialoguer la WLL avec la DAL ?

L'idée étant d'obtenir un environnement de développemnt entièrement partageable. (Objet Client / Article utilisable par X appli par exemple)
Autres exemple, nous ne souhaitons pas qu'une modification dans l'objet de connexion à une BDD entraine une recompilation et un re-déploiement de toutes nos applis...

Les solutions me venant en tête sont les suivantes :

- Web services
- .NET Remoting
- WCF

Suis-je sur la bonne piste ? Est-ce une architecture standard et éprouvée ?
Existe t-elle (lol) ?

Merci d'avance pour le temps que vous avez consacré à lire mon soucis ainsi que le temps que vous prendrez pour y répondre !

@++

Ps : Bon Week-end (je ne pense pas repasser sur ce forum avant lundi )

[_skip]

Sans quelques informations sur le nombre d'utilisateur et le style d'application ce serait difficile de proposer quelque chose.

Les technologies que vous citez sont typiquement utilisées dans les clients légers et les applications distribuées ou orientées service mais on peut très bien concevoir un client lourd en 3/tiers aussi.

Le 3/tiers est à voir comme une manière générale de réfléchir plutot qu'une loi stricte en béton armé.
Ensuite la mise en oeuvre dépend si vous souhaitez avoir un seul process de votre cru qui fait la connexion à la base de donnée et sert les applications clientes (ce qui a des avantages mais également des inconvénients) ou si vous pensez plutôt à une architecture ou chaque client se connecte directement à une base de donnée Client-Serveur.

[Bal1n]

Bonjour

Tout d'abord merci de votre réponse !

En ce qui concerne le nombre d'utilisateur, ceci est très variable suivant l'application. De plus le nombre d'utilisateurs/d'applications devrait croître de façon importante d'ici les 2 prochaines années.

En gros aujourd'hui, les applis orientées 'Métier' sont développées sur Asp et disponible via intranet. Ce sont pour la plupart des 'verrues' proposant un rendu que notre ERP est incapable de fournir. Certaines applis sont utilisées par 1 personne, d'autres par une dizaine.

De même, par exemple, les applis utilisées par 1 personne sont souvent crucial ! (outil de planification de fabrication par exemple)

Nous souhaitons conserver cette distribution par client léger afin d'avoir à éviter de distribuer des clients lourd partout. Nos postes de travail étant relativement verouillé par GPO on souhaite s'éviter des problèmes de mise en place en passant par intranet. Nous avons également quelques client Lourd servant uniquement pour l'informatique et interrogeant l'AD par exemple.

En ce qui concerne la mise en oeuvre, nous aimerions que nos applis clientes dialogue uniquement avec des objets métier. Ces objets métier dialogant eux mêmes avec la couche DAL pour tout ce qui est connexion/interrogation de BDD. L'objectif étant en partit de faire développer la couche présentation par des BTS IG en alternance. Puis les faire évoluer vers la couche métier et donnée en même temps que leur montée en compétence.

Notre principale interrogation étant que nous ne savons pas comment partagé un objet Métier (comme 'Article' par exemple) à un ensemble d'application. L'idéal serait qu'une modif de l'objet article ne doit pas entraîner une recompilation des programmes.

Une idée ?

[_skip]

L'une des façon de faire en effet, ce serait donc de développer une couches BL comprenant les objets métiers et une couche DAL chargée des requetes dans la base de données.

Ensuite vous publiez une interface destinée aux couches de présentation (web ou winapp) qui fait office de façade sur votre couche métier, le .Net Remoting fait du bon boulot en ce sens (en client ou server activated ) sinon vous avez WCF qui je pense, est une bonne solution mais je manque d'expérience avec cette technologie. Les webservices quant à eux sont peut être un peu trop stateless (je dis bien "peut être").

Vous devez tenir compte du fait qu'étant donné que les objets seront distribués entre la présentation et la BL ils devront être sérialisés, Ils doivent donc être très indépendant de la DAL (pas de méthode Save() avec une connexion donc).
La sérialisation et déserialisation a aussi un cout question performance, donc si vous avez l'habitude de faire des requetes ramenant 15000 enregistrements sur l'application client, le PC le sentira passer (tout comme le réseau).

[Bal1n]

Ok

Bon il va falloir que je me colle à une des 3 technologies que vous cité histoire de bien comprendre comment cela fonctionne.

pas de méthode Save() avec une connexion donc

Quid des interfaces de saisie alors ? (Méthode AddArticle() par exemple)
Quel est la solution pour que le client puisse effectuer une MàJ de la BDD dans ce cas ?
La serialisation (...processus de conversion de l'état d'un objet en une forme enregistrable ou transportable...) empêche cela mais pourquoi ?

Désolé de vous torturer comme cela et merci encore pour votre aide !

[bizet]

Salut

Voila une archi que j'ai utilisée dans un projet et qui semblait bien fonctionner.

Une couche Data qui consiste à "simplement" faire les appels en BDD. Les fonctions renvoient uniquement un Objet ou une liste d'objet.

Une couche métier qui se décomposent en plusieurs blocs. Le premier "Objet" qui contient l'ensemble des objets métier de ton projet. Le code métier qui fait toute sa sauce avec les appels en BDD et un bloc interface qui propose les classes que la couche présentation peut appeler.

Et une couche présentation pour l'affichage à l'utilisateur.

Entre la couche presentation et metier, tu peux rajouter un bloc communication qui va permettre de modifier facilement le mode de communication entre les deux couches. Par exemple une fonctionnalité de ta couche présentation va appeler tout le temps une fonction de ta couche comm. Selon ce que tu auras décidé elle utilisera l'accès direct, le WS, .Net remoting,... pour appeler la fonction du bloc comm coté metier.

Si tu dispatch tous les blocs sous forme de librairie, quand tu modifies une classe, tu n'as plus qu'à livrer la librairie modifiée et non l'ensemble de l'applis.

Est ce la meilleure implémentation, j'en sais rien, mais dans le cas du projet sur lequel j'ai bossé ça fonctionnait pas mal.

[_skip]

Quid des interfaces de saisie alors ? (Méthode AddArticle() par exemple)
Quel est la solution pour que le client puisse effectuer une MàJ de la BDD dans ce cas ?
La serialisation (...processus de conversion de l'état d'un objet en une forme enregistrable ou transportable...) empêche cela mais pourquoi ?

Ce que je veux dire, c'est que vous ne pouvez pas vraiment balancer des objets Self Service (comprenant des infos de persistence) a votre couche métier a travers un service style remoting.

Il vous faut des méthodes comme par exemple
AddArticle( int id, string nom, ...) ou meme AddArticle( ArticleEntity art) qui elles gèrent la persistence.

[Bal1n]

Ah d'accord dans ce cas
Ok je comprends mieux

Je vais m'atteler à faire une application de test en remoting via un serveur d'application et notre serveur de BDD.

En tout cas merci à vous deux pour vos informations très utiles.

Je marque ce sujet comme résolu !

Au plaisir

[_skip]

Vous avez pensé à un ORM?

[Bal1n]

Plop c'est re-moi

J'ai un petit 'Cas pratique' qui me turlupine.

L'objectif de ce test étant d'obtenir la liste des article vendu par un client.

Les règles de gestion sont : Un client peut commander de 1 à n article et un article ne peut etre commander que par 1 et 1 seul client. (c'est un test hein )

Donc si on rapporte cela à une architecture n-tier :

DAL :
-Objet de connection à la BDD
-Objet représentant les client.
-Objet représentant les article.

BLL :
-Objet métier 'ClientArticle'

Présentation :
-ASp.net

Ok ! Mon souci étant de savoir ou je place cette requête ?
Select * from Article where CodeCLient = 'toto'

Au niveau de ma DAL ? Dois je implémenter une méthode dans mon objet article du style GetArticle(Client as int)

Pour moi la couche BLL ne doit pas intégré de requête j'ai bon ?

Mais dans ce cas, ne risque t'on pas de ce retrouvé avec beaucoup de méthode dans l'objet article ?

[_skip]

Tout d'abord, je vous prie de m'excuser de ne pas répondre directement à votre question. Mais avez-vous déjà choisi un outil de mapping objet?
C'est une composante clé d'une bonne architecture multi tiers.

Cela vous permettra déjà d'avoir une meilleure vision du tout et apportera peut être la réponse à votre question.

[Bal1n]

Vous avez pensé à un ORM?

Oups désolé je n'avais pas vu votre question !


Ah non

Est-ce une obligation ? Peux-t'on s'en passer ?
Encore une chose que je connais très mal... Il faut que je check sur le Web pour voir en quoi cela pourrait nous être bénéfique avant d'approfondir dans mes questions.

Dur dur de changer de techno et d'architecture lorsque l'on est un simple Dév à la base !

[_skip]

Est-ce une obligation ? Peux-t'on s'en passer ?

Non ce n'est pas une obligation, et oui on peut s'en passer, quant à savoir si on a *intérêt* à s'en passer, là je dirai non.
Ce genre d'outil vous permet de focaliser votre temps sur la logique de votre application plutot que sur les opérations rébarbatives tels que les INSERT/UPDATE/DELETE dans vos différentes tables.
Je vous le recommande fortement.

Dur dur de changer de techno et d'architecture lorsque l'on est un simple Dév à la base !

La différence entre un apprenant super motivé et un ingénieur peut devenir très mince parfois... Je le sais pour avoir été les deux.