N tiers et client lourd

**rvzip64** · 19/08/2009, 10h37

bonjour tout le monde,

Je susi entrain de faire une appli en C# qui utilise les WinForms.
J'ai regardé la technique qui consiste à developper une application en 3 tiers, mais j'ai l impression que c est trés orienté vers le Web.

Est ce pertinent de développer une appli en 3 tiers pour un client lourd ?
Quel est la méthode le plus souvent utilisée ?

Merci d'avance

**Pol63** · 19/08/2009, 10h44

pas expert mais je dirais :
une base de données, un .exe serveur, un .exe client

le client ne se connecte donc pas directement à la base ; plus de sécurité (au moins pour ceux qui savent pas le faire sur le sgbdr), moins de licenses sgbd à acheter ^^
possibilité de faire des notifications entre le serveur et le client (certains sgbdr le font, mais pas aussi bien qu'un exe je pense)

après pour la comm entre serveur et client, y a .net remoting et WCF au moins (socket pour les courageux)

**rvzip64** · 19/08/2009, 11h05

Merci pour té réponse Pol63

A l'heure actuelle j'utilise MySql et le client se connecte en directe à la base de données. Je trouve cette méthode bien plus pratique que d'avoir un exe sur le serveur....

**Pol63** · 19/08/2009, 11h08

comme je disais pour avoir de la notification c'est pratique, parce que si un client change un truc, c'est parfois de le répercuter à l'affichage sur les autres clients dans la foulée

mais si t'as pas besoin ou que tu as trouvé un autre moyen de faire ca oui ca peut etre inutile ...

**Philippe Vialatte** · 19/08/2009, 11h12

Ce qui a été proposé par Pol63 est une architecture justement middleware, pas une architecture n-tiers, qui n'est pas, non, réservée aux applications web. Le principe d'une n-tiers, ça reste la séparation du code : couche IHM (ton application WinForms), couche Objet Métier (une bibliothèque) et couche Accès aux données (une autre bibliothèque)..

Faux...

n-tiers -> le client s'execute qq part, et les n-1 serveurs ailleurs...
ce dont tu parles, c'est d'un decoupage en couche, qui est un decoupage logique, le n-tiers est un decoupage physique

A l'heure actuelle j'utilise MySql et le client se connecte en directe à la base de données. Je trouve cette méthode bien plus pratique que d'avoir un exe sur le serveur....

L'avantage de la répartition en N-tiers, c'est aussi la scalabilite...si c'est bien fait, tu peux ajouter des machines ou des tiers sans tout casser (genre, passer sur n bases de donnees, ajouter des machines qui font des calculs entre...)

**rvzip64** · 19/08/2009, 11h20

Ok déja je viens de découvrir qu'une appli n-tiers utilisait plusieurs serveurs.

A l'heure actuelle ce n'est pas mon cas, je vais plus utiliser un découpage logique de mon application que physique.

Est ce que je dois "caler" mon découpage des couches logiques, sur un hypothétique découpage physique ?

**Kaidan** · 19/08/2009, 11h21

Hum ...

http://fr.wikipedia.org/wiki/Architecture_trois_tiers

L'architecture 3-tier (de l'anglais tier signifiant étage ou niveau) est un modèle logique d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :

la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur ;

le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative ;

et enfin l' accès aux données persistantes (persistence en anglais) : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.

La définition de Wikipédia est fausse ? Ou alors 3-Tier n'est pas un N-Tier ?

**Philippe Vialatte** · 19/08/2009, 11h37

Envoyé par Kaidan

Hum ...

http://fr.wikipedia.org/wiki/Architecture_trois_tiers

La définition de Wikipédia est fausse ? Ou alors 3-Tier n'est pas un N-Tier ?

Je dirais reponse 1

Il y'a des pb de trad entre anglais et francais, et souvent, en francais, on appelle tiers des couches applicatives...

http://en.wikipedia.org/wiki/Multitier_architecture

1 tier = un serveur
1 layer = une couche applicative

**Kaidan** · 19/08/2009, 11h07

Envoyé par Pol63

moins de licenses sgbd à acheter ^^

Ce n'est pas vrai dans la plupart des cas : la licence SQL Server spécifie bien qu'un utilisateur (qui doit donc avoir une licence) est un utilisateur final ... peut importe combien de middleware il y a entre le client et le serveur de base de donnée.

Donc, 50 utilisateurs => 1 middleware => 50 licences...

C'est pour ça qu'en général, on opte pour une licence Serveur dans le cas du Web : on ne sait pas à l'avance combien d'utilisateurs "finaux" on va avoir.

Ce qui a été proposé par Pol63 est une architecture justement middleware, pas une architecture n-tiers, qui n'est pas, non, réservée aux applications web. Le principe d'une n-tiers, ça reste la séparation du code : couche IHM (ton application WinForms), couche Objet Métier (une bibliothèque) et couche Accès aux données (une autre bibliothèque). La couche IHM appelle la couche métier qui se charge d'appeller la couche accès aux données pour lire/écriture les données sur le SGBD. L'utilisation d'interfaces entre les différentes couches permet de remplacer simplement une ou plusieurs couches sans forcément toucher tout le développement.

**Pol63** · 19/08/2009, 11h30

Envoyé par Kaidan

la licence SQL Server spécifie bien qu'un utilisateur (qui doit donc avoir une licence) est un utilisateur final ... peut importe combien de middleware il y a entre le client et le serveur de base de donnée.

Donc, 50 utilisateurs => 1 middleware => 50 licences...

si t'as un lien je suis preneur, je vois rien de si explicite ici et là ...

**Kaidan** · 19/08/2009, 12h22

Envoyé par Pol63

si t'as un lien je suis preneur, je vois rien de si explicite ici et là ...

Sometimes organizations develop network scenarios that use various forms of hardware and/or software that reduce the number of devices or users that directly access or use the software on a particular server, often called multiplexing or pooling hardware or software. Use of such multiplexing or pooling hardware and/or software does not reduce the number of CALs required to access or use SQL Server software. A CAL is required for each distinct device or user that is connected to the multiplexing or pooling software or hardware front end.

This is true no matter how many tiers of hardware or software exist between the SQL Server and the client devices that ultimately use its data, services or functionality. An exception to this includes the manual transfer of data from employee to employee. For example, if an employee sends an Excel version of a report to another employee, the receiving employee does not require a CAL (as long as the report does not access a SQL Server in some way). An additional exception is communication exclusively between SQL servers.

Page 1 de http://download.microsoft.com/downlo...w%20final.docx