Discussion :

[chrisdot]

Bonjour tout le monde.

Je viens de voir le post précédent concernant l'accès aux données depuis silverlight.
Je me pose le même genre de questions, mais de façon un peu plus large. Je dois développer une application silverlight orientées données.

Comme DAL, j'ai pensé à Entity Framework, mais là n'est pas mon problème. Mon principal problème est le choix de la couche intermédiaire: le transport de données, mais surtout la mise à jour/répercussion ensuite.

Le problème est qu'il va falloir que je supporte tous les cas de figure. Pas simplement la lecture de données, mais:

• la mise à jour simple d'une entité
• la création de nouvelles entités
• la suppression d'entités
• la mise en place de liens entre les entités

De plus j'ai des contraintes de "lazy loading": je ne veux pas charger l'ensemble des données si ce n'est pas nécessaire (genre d'écran liste/détails).

J'ai commencé par essayer ADO .NET data services (suite au bouquin "Data driven Serviceswith Silverlight 2" qui est pas mal d'ailleurs) pour accéder à mes entités EF. J'ai rapidement réussi à trouver des exemples simples et j'ai réussi à jeter les prémices d'une application simple gérant même le lazy loading.

Ensuite où les choses se gâtent c'est pour remettre à jour le DataServiceContext. Pour une mise à jour d'un champ, pas trop de problèmes, mais dans un cas de mix entre suppression+ajout+modification de champ+mise à jour de lien vers une autre entité, ça devient ingérable.

Je cherche donc un exemple plus complet de gestion des reports des modifications vers le DataServiceContext.

Sinon, je suis aussi ouvert à toute autre piste, même du style services WCF + EF derrière... Par contre, je suppose qu'il va falloir que je gère plus ou moins le même mécanisme.

Des idées?? Ou surtout des exemples??

Merci
Christophe

[Thomas Lebrun]

Pourquoi pas tout simplement EF + WCF, le lazy loading étant fait par EF ?

[chrisdot]

Merci pour ta réponse.

Effectivement, comme je l'ai dit, c'est une possibilité que je suis en train d'étudier. Par contre ça ne change en rien mon problème fondammental.
Il va bien falloir que je gère les modifications et que je les reporte dans l'EF à ce moment là. Que j'utilise l'EF à travers ado .net data services ou non, il me faudra stocker tous les changements et les répercuter au moment ou l'utilisateur choisira de tout sauvergarder.
Avec astoria, il faudra que je mette à jour le "dataseervicecontext", et dans le cas de l'EF à travers WCF, le "context" (plus ou moins de la même manière).

En fait, c'est plus une question d'architecture que je me pose. Comment organiser tout cela pour pouvoir répercuter facilement mes changements dans le context ou dataservicecontext?

Christophe

[Thomas Lebrun]

C'est à toi de faire les méthodes d'ajout/suppression/modification qui vont utiliser le context EF et qui seront exposées à Silverlight via WCF.

[chrisdot]

Oui je sais bien. Mais je cherche une idée/un exemple d'architecture. Un adaptateur au dessus de chaque entité... autre???

Les exemples que j'ai pu trouver sont simplistes: read/update d'un champ...

Sinon, j'ai pensé à utiliser Persistence Ignorance (POCO) Adapter, mais je ne sais pas ce que ça vaut.

Christophe