Architecture d'un logiciel en réseauRésolu

Question

Bonjour à tous,

J'ai pour objectif de développer un logiciel de gestion pour un commerce.
Ce logiciel comprendra entre autre un module de caisse et un module de gestion du stock.
Sachant que plusieurs utilisateurs seront amenés à travailler simultanément sur ce logiciel
sur des postes différents et que chacun d'eux pourra utiliser l'ensemble des fonctionnalités du logiciel, ma question, en 3 partie, est la suivante : 

1. vaut-il mieux : 
    A. installer le logiciel sur chaque poste ( et partager la base de données qui sera sur l'un d'eux ou sur un serveur)
    B. installer le logiciel uniquement sur un seul poste et créer un lien vers celui-ci depuis les autres postes ?

2. Y'a-t-il une autre solution ?
3. Quelles sont les contraintes de chacune d'elles ?

Pour info, je compte utiliser le langage C# et une bdd firebird.

D'avance merci pour vos réponses.
Brad.

Nikoui · Accepted Answer

Bonjour,

A quoi penses-tu exactement dans la solution "B" quand tu parles de 'lien" vers ton application ?

En fait, dans ton cas, j'opterai pour la solution suivante :
- faire une architecture client/server -> mettre entre ton application (ton client) et ta base de données une autre application (le server). Seul le serveur accède à la base de données, et plusieurs clients dialoguent avec le serveur.
(tu peux aussi voir avec une architecture "n-tier", et remplacer le serveur par des "services" et rajouter d'autres couches d'abstraction, mais tu n'en pas nécessairement besoin...)

Même si la solution A est a priori envisageable, je te la déconseille, car a partir du moment ou plusieurs utilisateur accèdent à la même base de données, tu vas rencontrer les problèmes suivants :
- Modification simultanées d'une même information en base par plusieurs utilisateur (bon, normalement le base de données sait gérer ça)
- Plus globalement, problème de synchronisation entre le contenu de la base et ce que manipule l'utilisateur : imagine que 2 utilisateurs travaillent sur le même formulaire : si un utilisateur enregistre ses modifications, elles seront stockées en base de données, mais l'autre utilisateur continuera a travailler avec son formulaire, contenant les anciennes valeurs -> lorsqu'il enregistrera ses données, comment gérer le conflit ?

Le fait d'ajouter une couche entre la base de données et le client (c'est à dire rajouter un serveur) te permet de contrôler tout ça, et de valider ce que tu écris en base ou non. Par exemple, dans le cas précédent, le serveur peut déterminer qu'un utilisateur vient de modifier un formulaire, et "prévenir" (notifier) les autres utilisateurs de cette modification (ce que tu peux difficilement faire avec une base de données (même si ça reste techniquement faisable))

Par contre, une architecture client / server ammène un peu plus de complexité, notament dans la gestion des connexions entre clients et serveur, et encore plein d'autres choses :) Mais c'est quelque chose de classique donc les problèmes et les solutions sont bien connus...

Pour résumer, dans ton cas je regarderai du côté d'une architecture client server classique (3-tier), ou bien du côté d'une architecture n-tier, qui peut être aussi adaptée à ton problème.

<hr size="2" width="100%" />
Working as designed
www.nikoui.fr

bradlemon · Answer

Merci Nikoui pour ta réponse rapide et précise.

Concernant la solution B, je voulais en fait parler de raccourci vers le programme.

Le fait de rajouter une couche entre le client et la base permet en effet de maitriser d'avantage la cohérence au niveau des données, mais qu'en est-il du temps de réponse. Je tiens à ce que le caissier qui scanne son article ai une réponse instantanée (lorsqu'il récupère le prix de vente, le pourcentage de remise, le taux de tva, etc.). Le commerce en question est une supérette, les clients sont toujours pressés et peuvent être très nombreux à certaines heures...

Nikoui · Answer

Cette architecture ne te posera aucun problème de performance, surtout vu le contexte (a priori réseau dédié, et pas plus de quelques dizaines d'utilisateurs simultanés). De plus c'est vraiment une solution ultra classique pour ce genre de problématique, donc tu peux y aller les yeux fermés.

Attention par contre, c'est un peu plus complexe qu'une simple application qui va dialoguer directement avec une base de données, donc si tu débutes dans le domaine prévois du temps pour soigner le design et bien comprendre les tenants et les aboutissants.

<hr size="2" width="100%" />
Working as designed
www.nikoui.fr

bradlemon · Answer

Merci pour toutes ces infos Nikoui. Je vais de ce pas me plonger dans les bouquins et les forums d'architecture client / serveur. 

@+,
Brad

impsaid · Answer

Bonjour,
    
    Avec ClickOnce, l'installation et le lancement d'application se réalise
en un clic de souris depuis une page web ou un espace de partage
réseau. Au delà de ça, ClickOne résout le problème de mise à jours et
l'administration des machines clientes.

    Le déploiement ClickOnce permet de publier des applications Windows sur
un serveur Web ou un partage de fichiers réseau afin de simplifier
l'installation. Visual Studio assure une prise en charge complète de la
publication et de la mise à jour d'applications déployées à l'aide de
ClickOnce. Le déploiement ClickOnce est disponible pour les projets
créés avec Visual Basic, Visual C# et Visual J#, mais pas avec Visual
C++.

Architecture d'un logiciel en réseau

5 réponses

Votre réponse

Discussions similaires