Version imprimable
Salut tout le mond
Je veux savoir quel est la meilleure architecture à utiliser avec la technologie Silverlight 2.0.
Dans le cadre d'une architecture en 3 couches :
- Graphic User Interface (GUI)
- Business Object Layer (BOL)
- Data Access Layer (DAL)
- Business Logic Layer (BLL)
Le GUI, la BLL, la BOL je sais comment faire. Mais pour la DAL, j'ai pas assez bien compris ?
Ben c'est comme tu veux, mais dans tous les cas tu aura un Service (WCF ou autre).Citation:
Envoyé par h2s84
GUI -> Business -> Service -> Data
Skyounet a ditMerci pour ta reponse. Je vais me renseigner les WCF pour voir. J'espère que c'est pas très compliqué.:roll:Citation:
dans tous les cas tu aura un Service (WCF ou autre).
J'ai oublié de préciser.
Le service est obligatoire seulement si tu souhaites communiquer avec une BDD.
la DAL, comme son nom l'indique est dédié à l'accès aux données, donc tous ce qui est dédié à la connexion à la base de données, les requêtes est dans cette partie (dans le cas où les données sont stocké en bdd ...).
Ce que je ne comprends pas par contre, c'est si tu as compris comment faire les 3 autres, en quoi la DAL te pose problème ? BLL pour le métier, BOL tes objets, GUI présentation, il ne te reste qu'à gérer la persistance de tes objets, donc la DAL !
Tu veux utiliser quoi comme mécanisme ou framework pour la persistance ? (toujours dans le cas où c'est une base de données) ... Il y a la solution classique de ADO.NET ... Il y a aussi des ORM, EF (3.5), nHibernate ... Qui t'aideront à construire ta DAL ...
Pour WCF si tu connais les Web Services (2.0) ça devrait pas être compliqué ... Tu peux utiliser aussi ADO.NET Data Services (REST) ...
rad_hass a dit :Avec silverlight le code de l'appli est téléchargé chez le client alors qu'avec ASP.Net on avait le contraire (Seul le code HTML est envoyé au client). Je ne veux pas allourdir le fichier xap avec mes assemblies DAL, BLL et BOL. Jeveux que ces derniers restent sur le serveur. Je pense que les services WCF pourront m'aider d'après ce que je pense. Si je ne suis pas sur le droit chemin ayez l'aimabilité de me préciser la meilleure façon de développer avec silverlight 2.0 ?Citation:
Ce que je ne comprends pas par contre, c'est si tu as compris comment faire les 3 autres, en quoi la DAL te pose problème ? BLL pour le métier, BOL tes objets, GUI présentation, il ne te reste qu'à gérer la persistance de tes objets, donc la DAL !
h2s84, faire du métier avec Silverlight, c’est possible, mais il y a du boulot. En effet, comme beaucoup de technos, Silverlight est plutôt orienté service que métier. C’est un bon choix, mais qui ne convient pas à tous les contextes professionnels. Du coup, répondre à votre question n’est pas facile, tant cela impacte de points et de possibilités.
Dans ce post, je souhaite apporter mon témoignage et encourager tous ceux qui veulent travailler ‘métier’. Je souhaite dire que c’est possible, mais aussi souligner que cela demande beaucoup d’efforts.
Petite réflexion pour planter le décor
H2s84, vous parlez d’alourdir le xap avec vos couches DAL, BLL et BOL. Vous voyez cela comme un problème et à mes yeux vous avez raison. Il réside une certaine impossibilité. Comment DAL pourrait être présent coté Silverlight alors qu’il est impossible de voir la base de données coté client ? Si DAL ne peut pas être mis coté Silverlight, comment BLL et BOL vont-ils communiquer avec la base de données ?
A moins d’envisager une architecture métier où DAL serait en fait une couche de communication directe avec le serveur pour effectuer des ordres de manipulation de données cela ne semble pas vraiment réalisable.
De plus, bien des règles métier exigent des ressources non accessibles depuis le client. Imaginez que vous ayez besoin au sein d’un certain process de faire appel à d’ancien process codés par exemple sous AS400 !
Pour moi, tout doit rester sur le serveur. Le client doit rester léger. Le client ne doit pas implémenter de règles métier.
Généralités
Ecrire une application métier en Silverlight (comme avec beaucoup d'autres technologies) pose une série problème lorsqu'il s'agit de bien respecter la logique de séparation des couches. Pourquoi ? Tout simplement parce que l'existence physique de deux couches logicielles aussi ‘éloignées’ que le client et le serveur met à rude épreuve la logique métier.
L’idée est de disposer d’une couche applicative métier c'est-à-dire implémentant les règles et les process métier de l’entreprise. On souhaite que cette couche soit unifiée, la plus indépendante possible des technologies, et surtout totalement découplée des autres couches applicatives. On souhaite aussi que cette couche métier soit la plus sécurisée possible, bien au chaud sur un serveur (ou un réseau de serveur). Ensuite, il ne reste plus qu’à exploiter ce métier de façon uniforme à partir d’autant de couches applicatives que nécessaire (un site Web, une application Intra, une application Mobile,…).
Oui mais. Si une règle métier est codée dans la couche applicative métier, au fin fond d’un serveur… Comment faire en sorte que cette règle s’applique au niveau d’une couche applicative UI ? Faut-il la récoder au niveau de cette couche UI ? Aberration ! Faut-il envisager de ‘télécharger’ du ‘code’ depuis le serveur ? Autre aberration !
Ma vision des choses
En ce qui me concerne, j'ai résolu le problème en mettant au point un framework et quelques outils propriétaires écrit en C#. Je travail avec ce framework depuis plusieurs années et je lui ajoute des modules au fur et a mesure des innovations technologiques (Pour tout dire, ce framework été à l’origine écrit en Delphi. Je l’ai porté courant 2003). A la date d’aujourd’hui, ce framework me permet d’implémenter mon métier de la façon décrite ci-dessus. A la date d’aujourd’hui Il intègre aussi des couches UI pour ASP.NET/Ajax ainsi que pour Silverlight.
Voici quelques caractéristiques du framework :
En parallèle du framework, j’ai écrit deux micro framework (un pour ASP.NET/Ajax, l’autre pour Silverlight). Ces micros framework intègrent chacun un ensemble d’outils et des contrôles cohérents gérer la partie IHM. Voici quelques caractéristiques du micro framework pour Silverlight que j’ai mis au point au cours des derniers mois dans le cadre d’un projet pour un client (l’idée générale reste la même pour ASP.NET/Ajax) :
- La couche d’accès aux données est implémentée de façon native (Dans l'état actuel des choses, c'est du Sql Serveur ou de l'Xml car je n'ai pas eu à faire face à d'autres besoins depuis que je travail sous DotNet. Mais toute autre techno pourrait être envisagée).
- La couche métier est construite sur un ensemble d'objets de base, solides et indépendants du contexte technologique. Ces objets sont réfléchis de façon à offrir un maximum de souplesse et de richesse fonctionnelle tout en garantissant la cohésion métier.
- Gestion de la sécurité.
- Gestion évoluée des erreurs : Un collecteur d’erreur permet de collecter l’ensemble des erreurs de validation afin de les remonter de façon cohérente jusqu’au niveau UI afin d’y être exploiter et afin d’offrir un maximum de confort à l’utilisateur.
- Gestion des traces : Les entrées et sorties de procédures peuvent être tracées. Les requêtes à la couche d’accès aux données peuvent aussi être tracées.
- Une foultitude de fonctionnalités pour faciliter l’écriture de règles métier très récurrentes dans beaucoup d’application. Particulièrement en ce qui concerne les règles de validation. Par exemple, la possibilité d’appliquer une expression régulière à une donnée spécifique.
- Définition de méta données associées aux entités ou aux données. Par exemple, les libellés des données peuvent être définis sous forme de métas données. Les masques de saisie, les masques d’affichage,…
- Multi langue et localisation des métas données natif.
- Un AddIn pour VS met à disposition des outils de productic. Ainsi, un simple clic permet de transformer toute une architecture de base de données en une architecture métier de base correspondante. Il ne reste plus qu’à enrichir les classes partielles définies par le métier. Si un changement dans la base survient, un simple clic régénère le modèle sans toucher à nos règles métier.
Conclusion
- Une couche communication permet le dialogue natif avec le métier. Aucun besoin d’implémenter le moindre service. Toutes les méthodes métier sont accessibles en synchrone et en asynchrone.
- Sécurité
- Possibilité de persistance des objets coté serveur (sur le disque / optimisation de l’utilisation de la mémoire).
- Optimisation des échanges (quelques octets bien souvent).
- Compression des échanges.
- Les contrôles exploitent la couche communication afin de garantir l’application des règles métier sans le moindre développement. Ils exploitent entre autre les métas données associées aux données. Par exemple, les formats de saisie ou d'affichage. Qu'il s'agisse des grilles, des zones de texte, des dropdown,...
Cela m'a demandé beaucoup d'effort pour aboutir à quelque chose que me convienne et réponde à mes besoins mais l'essentiel pour moi c'est qu'aujourd'hui je parviens à développer mes applications en me focalisant véritablement sur les règles métier que je dois implémenter. La conception des UIs ne me prends plus de temps, est simple, et respecte toutes mes règles métier sans que j'ai à me prendre la tête. Je code mon métier coté serveur, et il s’applique coté client sans que j’ai quoi que ce soit à faire.
C’est là mon témoignage pour encourager tous ceux qui rêvent de code métier bien propres à ne pas renoncer.
Ouverture
J’envisage depuis un moment de transformer mon framework en un projet Open Source, ou tout au moins de le mettre à disposition gratuitement. Mais devant le travail que nécessiterait la publication de mon framework (écriture de codes de démo, rédaction d'une documentation de prise en main, ouverture d'un forum, réponse aux messages,...) je m'interroge…
Comme je suis indépendant, je me dois de faire attention à l'usage de mon temps. Je ne veux pas non plus mettre à dispo une solution sans démarche qualité car je ne veux faire perdre de temps à personne.
Je serai donc très intéressé de connaitre les besoins dans ce domaine. J’aimerai peser, mesurer ces besoin afin de savoir si ça vaut la peine que je passe du temps à préparer une version gratuite.
J’aimerai aussi savoir si certains seraient volontaires pour par exemple apprendre à utiliser ce framework, faire des codes de démo, rédiger de la doc, créer des vidéos,…
Ce ne serait pas pour la semaine prochaine. Il s’agirait de se projeter dans les mois qui viennent… N’hésitez pas à me contacter.
Quoi qu’il en soit, je suis dispo pour partager mon expérience sur la façon dont j’ai résolu certains problèmes dans le cadre du développement d’architectures métier.
Merci à tous pour vos réponses et surtout à mlebreton. L'expérience fait la différence:king: