Forum, Gestion d'un mode déconnecté

**Bal1n** · 19/05/2009, 12h06

Bonjour à tous.

Voilà, je dois créer une appli pour des commerciaux de terrain.

Cette appli doit leur permettre "à la manière d'un forum" d'échanger des informations, des photos etc...

Jusque là facile

La problématique étant que ces commerciaux doivent disposer de l'appli en mode déconnecté.

Donc le but final de tout ca étant de pouvoir bosser sur l'appli en mode déconnecté ou connecté et de synchroniser les données avec la BDD lors d'une connexion au réseau d'entreprise.

Quel sont les solutions techniques qui pourrait selon vous être adapté à ce cas.

Personnellement j'ai pensé à :

** un client lourd avec BDD Local + des scripts de synchro avec la BDD de l'entreprise.

** bosser avec des fichiers XML pour les données mais les temps de réponse risque d'être monstrueux...

** ouverture d'un forum via internet / extranet. Le pb c'est qu'il n'y a pas de mode déconencté...

Bref avez vus des solutions technique en tête qui pourrait m'aider ?

Merci !
Cdt,
Balin

**Bluedeep** · 19/05/2009, 12h17

Envoyé par Bal1n

Personnellement j'ai pensé à :

** un client lourd avec BDD Local + des scripts de synchro avec la BDD de l'entreprise.

** bosser avec des fichiers XML pour les données mais les temps de réponse risque d'être monstrueux...

** ouverture d'un forum via internet / extranet. Le pb c'est qu'il n'y a pas de mode déconencté...

Bon, apparement tu as réflechi à ton problème.

Alors en substance (on va supporser que ton appli tourne sur PC portbable, pas du "mobiles" téléphone et autres PDA) :

- internet/intranet : ben, contradiction majeur avec ton cahier des charges.

- XML : choix douteux, un peu batard, je ne vois pas trop le bénéfice ici.

- Base local : si tu utilises Sql Server au niveau central, choisi SQL CE sur le portable et profite des services de synchro fait exprés pour cela.

A mon avis, le choix le plus élégant et le moins lourd (de loin)en DEV (puisqu'à part la gestion de la synchro qui concerne plus la prod - rien à développer ou presque, avec les services existants prévus pour cela - tu développe ton appli comme si elle était connecté.

Seule précaution : ne pas utiliser les fonctions disponibles sur Sql Server non disponibles sur SQL CE et désigner ta DAL en utilisant les interfaces aux objets plutôt que les objets eux mêmes, et une connection factory.

**Philippe Vialatte** · 19/05/2009, 12h38

+1 a toutes les remarques de Bluedeep

Après, petit conseil supplémentaire, si tu fais de la synchro, tu as interet a ce que tes cles primaires soient des GUID, comme ca, tu n'as pas a gerer les collisions de creation (il te restera les collisions d'update, c'est deja assez fun

)

Envoyé par Bal1n

La problématique étant que ces commerciaux doivent disposer de l'appli en mode déconnecté.

question bete, pourquoi ne pas economiser en developpement et payer aux commerciaux un abonnement 3G sur cle usb ? on a etudie ca il y'a qq annees, le cout du 3Getait trop eleve, mais de nos jours, ca se discute

**Bluedeep** · 19/05/2009, 12h49

Envoyé par Philippe Vialatte

Après, petit conseil supplémentaire, si tu fais de la synchro, tu as interet a ce que tes cles primaires soient des GUID, comme ca, tu n'as pas a gerer les collisions de creation (il te restera les collisions d'update, c'est deja assez fun

)

Bonne remarque , mais c'est chez moi devenu une habitude tellement ancrée que je l'ai pas mentionné; je fais comme cela pour d'autres raison que la synchro : l'idée qu'un objet n'acquiert sa "complétude" qu'une fois persisté dans la DB me défrise profondément - avec les PK en GUID, on peut instancier un objet et le passer à un autre contexte applicatif sans s'occuper de son état de persistance vis à vis de la DB. Une autre excellente raison pour ne pas utiliser les "séquences".

question bete, pourquoi ne pas economiser en developpement et payer aux commerciaux un abonnement 3G sur cle usb ? on a etudie ca il y'a qq annees, le cout du 3Getait trop eleve, mais de nos jours, ca se discute

Sauf que :
- la 3G n'est vraiment pas disponible partout et dans ce cas on passe en GPRS, c'est très lent. (je suis en panne d'internet à la maison, SFR nous a prété une clef 3G en attendant et c'est un désastre en temps de réponse).
- il n'existe pas d'abonnement illimité en volume -AFAIK- sur les clefs 3G (alors que ça existe pour les portables).
- si l'appli est proprement désignée (SQL CE + Server), il n'y a pas d'impact réél en coup de développement. (du fait de la dispo des services de synchro "tout fait").

Après tout dépend aussi combien de commerciaux ils ont.

**Bal1n** · 19/05/2009, 17h29

re bonjour,

Merci pour ces astuces.

Pour la guid ca me parait être une relativement bonne idée pour éviter de gérer les collisions d'insert.
Par contre je n'ai jamais fait ça. La GUID est-elle généré par SQL Serveur ou dois-je prévoir un script de génération de GUID ?
Sachant que pour moi un GUID c'est un code AlphaNumerique sur 30 caractère, je ne sais pas si vous parliez de la meme chose ?

De même, j'imagine que les probabilités sont rare pour qu'un enregistrement sur le poste A génère le meme guid sur le poste B mais bon. Sait-on jamais !

Sinon, bonne remarque ! Je n'avais pas pensé à la gestion des collisions en cas d'update.... ! Il va falloir que je réfléchisse à cela.

Sinon pour les clé 3G c'est niet. Cela représente un budget trop important (environ 60 commerciaux).
A l'origine, cette appli été développé et intégré à Lotus Notes. Vu que l'ensemble des postes sont passés sur Outlook le souhait est d'éviter de payer le renouvellement de licence.

Merci à vous deux en tout cas. Je visualise encore un peu plus les problématiques auquels je vais devoir faire face.

Cdt,
Balin

**Bluedeep** · 19/05/2009, 17h35

Envoyé par Bal1n

Par contre je n'ai jamais fait ça. La GUID est-elle généré par SQL Serveur ou dois-je prévoir un script de génération de GUID ?

Le plus simple est de le générer par l'instruction NewID() de T/SQL ou dans le stocker directement dans la propriétés ID (ou autre) de ton objet métier.; En c#, tu le généres avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Guid.NewGuid();

Sachant que pour moi un GUID c'est un code AlphaNumerique sur 30 caractère, je ne sais pas si vous parliez de la meme chose ?

C'est surtout un inditenficateur unique dans le temps et l'espace (c'est à dire que 2 GUID générés au même moment sur deux ordis sont différents).

De même, j'imagine que les probabilités sont rare pour qu'un enregistrement sur le poste A génère le meme guid sur le poste B mais bon. Sait-on jamais !

Mathématiquement la probabilité de collision est très très faible mais non nulle.
Pratiquement, cela ne s'est jamais vu en ... pas mal d'années sur quelques dizaines ou centaines de millions de machines.

**Philippe Vialatte** · 19/05/2009, 17h40

pour les guid, soit tu laisse sql server le generer, mais ca ne sert pas a grand chose, le mieux, c'est, avant l'insert dans ta base de donnees, de tester si l'id de ton objet est null.

Si il est null, c'est un nouveau, donc, avant de sauver, tu fais qq chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

customer.UniqueId = Guid.NewGuid();

-> grille

Si il n'est pas null, tu fais direct ton update

Pour le cout du GPS, j'ai trouve ca:
http://www.myadsl.fr/myadsl/offres/g...playtop=myadsl

(je sais, ca ne sert a rien, mais juste pour info...avec un bon accord cadre, on passe les 60 commerciaux sur un forfait, ca peut le faire...et leneo pro illimite voix + data est a 74 euros /mois de base...)
(desole, deformation professionelle, 2 ans dáudit telecom

)

**Bal1n** · 25/05/2009, 12h46

Ok

Alors pour les Guid j'ai testé et adopté

Merci encore pour l'aide apporté. J'espère que je pourrais mettre un jour mes humbles connaissance à votre service

Sinon pour la 3g ça a beaucoup d'avantage sauf que c'est hors de prix comparé à mon salaire et au prix que coutera le dev (a mon simple avis).
Pour la petite PME (grandissante !) que nous sommes je pense qu'il est plus sage de gérer le mode déconnecté.

N'empêche que j'en ferais part à mes interlocuteurs si pour eux l'instantané vaut le prix

Et vu que c'est des commerciaux, ils aiment forcément tout ce qui est "bling bling". Donc je pense que la 3G va leur plaire, par contre ca va pas être le cas du directeur financier je crois

Bonne prog à vous.
++