Discussion :

[Dargos30]

Bonjour tout le monde,

Je suis en fase de conception et d'analyse pour un client. Il désire une application en technologie dot.NET pour centraliser ces données.

Contexte :
Appelons l'application "Central", elle sera en technologie MVC en framework 3.5, avec une base de données SQL server 2008.

Je pense utiliser Entity Framework pour la couche d'acces aux données.

Web Service :

D'autre application interne ont besoins des données centraliser dans la base. On compte y accéder par des web service qui utilisera aussi la même couche entity framework.

Cette solution me parait correspondre aux besoins du client, mais comment puis je m'assurer des performance d'une tel architecture?

Faut-il mieux developper un seul web service qui accède à toute la base et à toutes les tables, ou plusieurs petit web services qui accède uniquement à leur besoins (3à 4 tables)?

Sachant qu'il veulent crypter les flux échangé et que les données échangé vont à terme fortement augmenté (table d'historisation).

Je sais que je vous donne pas d'ordre d'idée sur les quantitées de données échangé, la taille de la base devrait faire 800Mo. Cela reste assez abstrait, mais c'est une coneption .

Merci de votre aide.

[Invité]

Salut,

Cette solution me parait correspondre aux besoins du client, mais comment puis je m'assurer des performance d'une tel architecture?

tu utilises EF pour la couche d'accès aux données et ton service web (ASMX ou WCF) sera là pour la couche d'accès aux données.
Pour la couche d'accès aux données plusieurs tests effectués par des développeurs démontrent que EF génère des requêtes SQL performantes si le programmeur a pris soin de bien formuler sa requête Linq To Entities et surtout ne remonter que les données dont on a besoin (avec des bêtises on risque de charger toutes la base de données en mémoire).
Pour le service Web soit tu y mets directement la logique métier soit il se base sur une couche de logique métier intermédiaire. Pour la performance du service web si c'est du WCF tout dépendra de comment tu l'exposes, de comment tu gères le contexte et la concurrence. Une recherche sur le net te donnera plus d'infos là-dessus.

Faut-il mieux developper un seul web service qui accède à toute la base et à toutes les tables, ou plusieurs petit web services qui accède uniquement à leur besoins (3à 4 tables)?

Une règle qui me semble cohérente : Moins il y a requêtes à traiter plus le service web sera réactif.
A : Un seul web service pour plusieurs applications qui peuvent lui envoyer chacun N requêtes
B : Un service web par application cliente donc qui ne gérera que les N requêtes de l'application cliente.
Je pense B sera plus performant que A vu qu'avec cette architecture on a moins de requête à traiter et sera bien plus rapide pour les exécuter.

Sachant qu'il veulent crypter les flux échangé

Avec WCF, c'est facile de mettre en place le cryptage des messages SOAP échangés.

que les données échangé vont à terme fortement augmenté (table d'historisation).

Que les données soient nombreuses ou pas, c'est à toi d'améliorer ta couche d'accès aux données en ne remontant que les données dont chaque application a réellement besoin et ne surtout pas oublier qu'il y a la pagination qui est là pour te faciliter la tâche .

[Dargos30]

Merci pour ta réponse, j'aurai une derniere question sur cette architecture.

Au point de vue accès aux données :

les entitées qui vont accéder à la base vont être l'application "Central" et les n web services (en choississant la solution B qui me parait aussi plus pertinante).

On a donc un multi accès aux données, dois je configurer sql server d'une certaine facon pour ne pas avoir de problème? (transactionnelle)

[Invité]

On a donc un multi accès aux données, dois je configurer sql server d'une certaine facon pour ne pas avoir de problème? (transactionnelle)

Si tu utilises des procédures complexes pour mettre à jour des données alors là autant mettre en place une transaction pour être à l'abri. Par contre si ta couche d'accès aux données n'utilise que les méthodes d'insertion, d'update, et delete d'EF alors dans ce cas ne t'en fais pas, SQL Server génère automatiquement (actif par défaut mais peut-être désactivé ) des transactions pour ces genres de requêtes dites atomiques que lui envoie EF : INSERT, UPDATE et DELETE.
De plus EF gère la concurrence et te génère une exception de type OptimisticConcurrencyException s'il trouve que la donnée initialement chargée par l'une de tes applications n'est pas identique à celle se trouvant dans la base au moment de la mise à jour ou de la suppression.

[Dargos30]

Un + pour toi et un pour EF , il est trop fort le petit.

Encore une petite question, promis c'est la dernière :

Concernant l'archivage des flux échangés par le web service, peux tu me donner une piste pour sauvegarder ces informations.

En effet mon client me demande si on peut avoir un historique des flux échangés.

Je pense enregistré les info principale pour tous les flux :
- utlisateur
- ip
- date
etc...

De plus pour les flux d'écriture (update et insert), récupérer les data échangés.

Merci de ton aide

[Invité]

En effet mon client me demande si on peut avoir un historique des flux échangés.

Je ne vois trop bien ce que tu entends pas flux

Je pense enregistré les info principale pour tous les flux :
- utlisateur
- ip
- date
etc...
De plus pour les flux d'écriture (update et insert), récupérer les data échangés.

Je pense que tu veux tout simplement avoir un enregistreur (loggueur) qui te mets dans un fichier ou dans une table de la base de données toutes les actions effectuées par les différentes applications. C'est ça ?

[Dargos30]

Oui effectivement c'est un logueur au niveau des flux échangés entre le client et le web service.

Par exemple tel client c'est connecté au web service à tel heure etc ....

Si j'ai bonne mémoire on dois pouvoir l'activer dans la configuration d'un web service svc, couche déjà intégré dans WCF, non?

[Invité]

Si j'ai bonne mémoire on dois pouvoir l'activer dans la configuration d'un web service svc, couche déjà intégré dans WCF, non?

WCF te permet d'activer la journalisation des évènements. Tout est expliqué dans cette page. Bonne Lecture.

Sinon je te conseille vivement d'utiliser un loggeur tel que Log4Net au lieu d'enregistrer les messages entrant/sortant du service web. Avec Log4Net le format est largement personnalisable et plus facile même si le framework .Net te permet aussi de créer des Listenner personnalisés mais c'est un peu difficile