[VB.Net 2.0] Comment organiser un projet 3-tiers ?

Bonjour,

Je suis débutant en dotnet et je dois développer une application web qui repecte l'architecture 3-tiers.
- Ma première question est comment organise-t-on ce type de développement sous dotnet (j'arrive du monde J2EE et je n'arrive pas à organiser mon projet) ?
- Ma seconde, concerne les webservices, je dois développer un webservice et je me demandais comment doit se faire le passage des mes objets métiers aux objets retournés par mes webservices (je travaille avec des types complexes) ? dois-je redéfinir des objets spéciales pour mon webservices étant donné que je ne peux utiliser que des objets avec des propriétés public ?

Merci d'avance pour vos informations

Salut,

Je ne suis pas expert WebService, mais voilà ce que je pense :

D'abord je suppose que tu parles d'une architecture 3 tier logique (pas physique).

Citation:

---

Ma première question est comment organise-t-on ce type de développement sous dotnet (j'arrive du monde J2EE et je n'arrive pas à organiser mon projet) ?

---

Tu fais simplement autant de projets sous .Net que tu as de couches. Un projet WebService pour le WebService bien sur, et le reste des projets de type dll. Chaque couche utilisant uniquement celle juste sous elle. (ton WebService fait appel à ta couche métier qui elle même fait appel à ta couche données). Dans le cas d'un WebService ça veut aussi dire que le WebService est une coquille vide qui se contente de rediriger les appels a ses WebMethod à la couche du dessous.

Citation:

---

Ma seconde, concerne les webservices, je dois développer un webservice et je me demandais comment doit se faire le passage des mes objets métiers aux objets retournés par mes webservices (je travaille avec des types complexes) ? dois-je redéfinir des objets spéciales pour mon webservices étant donné que je ne peux utiliser que des objets avec des propriétés public ?

---

Mon conseil la dessus est de ne PAS utiliser tes objets metiers directement dans ton WebServices et de laisser VisualStudio générer ensuite tout un tas de classes merdiques. Mais plutot de définir des classes "interface" entre ton webservice et les clients du WebService, puis d'eventuellement redéfinir tes classes métiers en fonction de ces classes d'interface. Ces classes ne devront contenir que des données publiques (normal, avec un webservice tu n'echanges que des données, pas des objets au sens POO).[/quote]

Hum le thread semble abandonné par le posteur initial mais pour ceux que ça pourrait intéresser voilà un lien (intéressant justement :) ) sur le sujet : http://www.thinktecture.com/Resource...kthrough1.html

Je vous remercie de votre aide, elle m'a été bien utile