Transmis par: webmaster actif Mercredi 05 Février 2003 à 00:05
Enfin ! Après deux mois de développement intense et d'âpres discussions autour de l'Architecture du PetShop DNG, Thomas GIL nous présente aujourd'hui cette implémentation titanesque qui fera date dans l'histoire de DotNetGuru. Rappelez-vous que le PetShop DNG est avant tout un moyen pratique d'illustrer nos différentes recommandations en terme de conception et d'Architecture multi-couches. Le but n'est absolument pas de vous fournir un Framework applicatif prêt à l'emploi mais seulement un ensemble de briques logicielles ou Design Patterns fréquemment utilisés dans les Architectures n-tiers.
N'hésitez pas à télécharger et à tester les sources. La configuration requise est le Framework .NET + MSDE ou Sql Server ainsi que IIS pour les pages ASP.NET. L'application est bâtie sur un outil de mapping Objet/Relationnel à la manière des JDO en Java et fait appel à une couche de service (BLL) et une couche d'accès aux données (Data Abstract Layer) totalement interchangeables (Design Pattern Abstract Factory). Nous vous encourageons vivement à tester les performances générales de l'application qui tire partie d'un puissant cache Objet.
Et n'hésitez pas à commenter cette implémentation !
Vous tombez sur un probleme que je me pose souvent avec les objets metiers.
est-ce bien utile de faire des objets vides qui font perdre des perfs, compliquent la maintenance et pour 0 fonctionnalités ?
pourquoi ne pas taper directement sur les bases pour ces applications ?
Il faudrait n'ajouter l'objet metier que lorsque l'on en a besoin. exemple :
on veut permettre a petshop d'acceder aux clients qui sont dans SAP ... :
1 on reprend les interfaces de la classe client.
2 on transforme la classe client en ClientPetShop et on fait un objet ClientSap
3 la classe Client permet de gérer ces 2 objets.
n'est ce pas plus simple ? (que des objets vides, des objets techniques histoire d'avoir une couche...)
sinon pour faire un decoupage en couche il faut aller a cette url : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/AppArchCh2.asp
Yves-Marie
Re: DotNetGuru vous présente son PetShop
par Anonyme actif 05 Fév 2003 à 00:51
Petit oubli:
- lorsqu'on est dans le portlet d'authentification, il faudrait que le Cancel soit à CauseValidation à false et les LinkButtons (Account, Cart et Sign In) de même, sinon on ne resort jamais.
Bravo Tom pour cette appli , il est trop tard pour vraiment décordique rtout ça mais j'ai installer le PetShop en local ( le script sql ne contient pas les insert des donnéess ?)
Et j'ai tenté par exemple de modifier un compte directement en base en même temps que le user menait une consultation sur le portail, j'ai une erreur d'accès concurrent (normal j'imagine) mais après la page ne se rafraichit pas avec les données contenues dan la base. Cela m'amène à demander comment est gérer le cache des objets ici par DTM ?
deux questions :
combien de temps (homme jour) entre la décision et le résultat du petshop DNG (deux mois environ) mais en temps de travail ?
combien d'avis (personnes différentes) ont participées à son élaboration (Tom, Sami) ?
C'est pour avoir une échelle d'évaluation du temps projet?
Voici des questions posées par Didier Girard du site Application-servers.com. Désolé de les insérer sous la forme d'un commentaire mais je suis un très mauvais weblogers ;-) :
"PetShop DotNetGuru
Bravo a l'equipe DotNetGuru pour son implémentation du PetShop. Elle est de très bonne facture. Voici quelques remarques/questions :
L'implémentation met bien en lumière la pauvreté du framework dotnet sur la gestion des exceptions, il est nécessaire de lire le code pour être capable de traiter correctement les exceptions fonctionnelles :-(,
Admettons que l'on souhaite faire une mise à jour sur plusieurs objets métiers, comment véhiculer le contexte transactionnel sans amener d'adhérence à l'outil de mapping et sans altérer les signatures des méthodes des DAL ?
Pourquoi exposer les objets métiers jusque dans les services, et ne pas diffuser des vues sur les objets métiers ? "
Concernant les exceptions, je crois Didier qu'on partage la même opinion sur le sujet. Nous sommes les premiers à déplorer l'ordre Throws dans les signatures de méthodes, cela fait partie des grosses carence de C#.. Et les raisons de MS à ce sujet m'ont toujours paru un peu douteuses ..
Concernant le contexte transactionnel. C'est exactement pour ça que nous avons opté pour des classes d'implémentation de la BLL orientées DTM. Si tu lis attentivement le code de l'objet ISearchControler tu verras qu'on trouve des appels de ce type : PetShopDNG.DAL.DtmImpl.Services.*
La dépendance des BLL impl aux DAL impl est évidente et on ne s'en cache pas. Du coup, altérer les signatures des méthodes d'implémentation et rajouter un contexte transactionnel ou un appel aux API DTM n'est pas fondamentalement dangereux dans la mesure où on s'en prémunit grâce aux interfaces qui elles, ne doivent surtout pas être impactées par ces changements d'ordre techniques.
Ceci dit ta remarque est réellement pertinente car il manque effectivement quelque chose semblable aux EJB ou à l'AOP qui permet de passer un contexte Tx de manière transparente. .NET 2.0 ? ;-)
Concernant ta dernière question sur pourquoi ne pas utiliser des valueObject ou un modèle entre les clients et les objets métiers, ça a été une longue et intense discussion entre Tom et moi. Nous avons conclu (et Tom m'a réellement convaincu) que l'utilisation d'un ValueObject pour obligerait à nous déconnecter de l'outil de mapping et du cache Objet. On serait constamment en train de copier des Objets métier pour ensuite les resynchroniser avec l'outil, ce qui serait dommage. Ceci dit (encore une fois), ta remarque est tout à fait judicieuse lorsqu'on souhaite masquer au client le type réel des Objets métier mais encore une fois, le client n'a jamais que l'interface de l'objet même s'il manipule réellement son implémentation DTM.
En fait, ta remarque prend toute sa valeur dans un monde distribué où il nous serait effectivement impossible de passer l'objet DTM au client. C'est justement pour ça que les EJB 1.1 utilisent ce Design Pattern. Et si on observent la dernière spécification EJB 2.0, on s'aperçoit que les EJB locaux ne sont rien d'autres que des Objet métier qu'on passe directement au client ... Tiens tiens ;-) ....
Mais tu as décidément l'oeil aguerri mon cher Didier, si seulement ce type de discussion pouvait avoir lieu plus fréquemment entre les deux communautés ...
Je suis assez frappé de voir que la plupart des applications de référence, quel que soit leur concepteur, ne comportent pas de back-office.
Certes, les enjeux de performance sont en général concentrés sur le front-office, mais les back-offices présentent de jolis challenges en termes de maintenabilité et d'ergonomie.
Qu'en pensez-vous, chers gurus?
Bonsoir,
Tout d'abord bravo aux deux concepteurs, c'est du beau travail, très pédagogique (je suis formateur).
1) J'ai téléchargé la version 1.01, il semblerait que le script creation.sql ne s'installe pas. Je l'ai trouvé dans le zip et le chargement s'est bien passé.
2) La démonstration de l'intérêt du respect des couches est évidente, même si je n'ai pas (encore) tout vraiment compris (au sens maîtrisé), mais ne pourrait-on pas envisager une version "dégradée" et pour tout dire plus abordable au "vulgum pecus" ?
Je pense notamment aux petits projets réalisés par des personnes (bac +2) n'ayant pas ce niveau de connaissances et de maîtrise des concepts manipulés (bac + 4/5).
Alain
Question certainement idiote, mais mon grade de débutant en .NET y est certainement pour quelque chose.
Qu'en serait-il d'un PetShop en plusieurs langues? Cette caractéristique influerait-elle sur votre architecture?
Question PostBack
par Anonyme actif 14 Fév 2003 à 15:56
Vu qu'on reste toujours sur la même page, comment remplace-t-on les tests
En réaction à un commentaire posté dans le forum "Bavardages" et concernant ColdFusion, j'ai établi quelques statistiques sur le nombre de lignes de code du PetShopDNG.
Attention, ces infos sont à corréler à notre architecture : on pourrait aisément diminuer le nombre de lignes de code, mais pas sans apauvrir l'architecture actuelle, ni sans porter atteinte à sa flexibilité.
Avec commentaires
- 69 classes C#, soit 2077 lignes
- 20 pages ASPX / ASCX, soit 774 lignes
Sans commentaires
- 69 classes C#, soit 1608 lignes
- 20 pages ASPX/ASCX, soit 749 lignes
Vous notez que je n'ai pas beaucoup commenté les pages ASPX ni les contrôles ASCX, contrairement aux classes C# qui comportent 25% de commentaires.
Une précision, tout de même : je n'ai pas comptabilisé le code généré automatiquement par Evaluant DTM, étant donné que tout est déduit du diagramme de classes UML et que je n'ai tapé aucune de ces ligens de code.
Mais pour information, sachez qu'il représente :
- 16329 lignes de code commentées
- 11007 lignes sans commentaires.
C'est beaucoup. Si nous avions développé la couche DAO manuellement, rassurez-vous, il y aurait eu beaucoup moins de lignes, puisque DTM génère pour chaque classe les mêmes méthodes génériques, dont nous ne nous servons pas forcément.
Voilà. Moralité, 1600 lignes de code C# pour notre PetShopDNG, c'est quasiment aussi bien que celui de Macromedia ColdFusion (1500), et c'est beaucoup moins que le PetShop Microsoft (3500) ou que celui de Sun (14000).
Mais mon sentiment personnel reste que les métriques de conception et d'architecture (nombre de dépendances inter-packages, couplage, flexibilité, ouverture...) sont bien plus importantes que le seul nombre de lignes de code.
Re: DotNetGuru vous présente son PetShop .NET
par Anonyme actif 25 Mar 2003 à 11:32
PREAMBULE
Avant tout, merci pour votre travail, qui a le mérite de nous faire réfléchir!
INTRODUCTION
Admettons que je souhaite porter DNGPetShop sur un framework de persistence fonctionnant sur des principes similaires à Hibernate, c'est à dire qu'on accède aux objets persistents via une notion de "Session", une Session étant un objet léger, non thread-safe, et qui implémente notamment un cache d'objets. Appellons ce framework "Xyz".
Par exmemple, pour augmenter le prix d'un produit de 10%:
Session s = Xyz.OpenSession();
Product p = s.RetrieveById(typeof(Product), 1234);
p.Price *= 0.10;
s.Store(p);
s.Close();
Notez bien qu'on fait s.Store(p) et pas p.Store(), et qu'il faut que ce soit la même Session qui fasse le RetrieveById() et le Store(), pour cause de cache d'objets. En résumé, tous les accès aux objets persistents nécessaires au traitement d'une page devraient passer par la même Session. C'est aussi au niveau des Sessions que se gèrent les transactions:
Transaction t = Session.BeginTransaction();
LE PROBLEME
Je me heurte à la difficulté suivante: où et comment conserver la Session utilisée pour servir une page? Pour respecter le principe des couches et d'indépendance vis à vis de la solution de persistence, impossible de remonter cette session dans le contexte http par exemple.
Exemple pratique: comment conserver la session qui récupère le IAccount dans AuthenticationController.Authenticate(), de façon à pouvoir la réutiliser dans AuthenticationController.UpdateAccount()?
Pour le principe, je voudrais ne rien modifier de la partie "générique" de DNGPetShop, mais j'avoue que je sèche.
Le mieux que j'ai trouvé est de modifier la classe BLL.AbstractFactory pour qu'elle instancie une nouvelle BLL.XyzImpl.XyzAbstractFactory à chaque appel à sa propriété statique Factory, plutôt que de conserver une unique BLL.DTM.DtmAbstractFactory dans un champ statique. Ensuite, la classe XyzAbstractFactory se charge de créer une Session, de la transmettre aux controlleurs, etc.
Mais cela demande de modifier une classe (BLL.AbstractFactory) que je ne souhaite pas modifier.
OBJECTION
On peut objecter je ne devrais pas remonter des objets liés à la solution de persistence jusqu'à la couche de présentation. C'est possible, il suffit de "détacher" l'objet de sa Session:
Session s = Xyz.OpenSession();
Account a = s.RetrieveById(typeof(Account), 1234);
s.Detach(a);
s.Close();
return a;
Puis de le ré-attacher à une Session après la modification:
Session s = Xyz.OpenSession();
s.Attach(a);
s.Store(a);
s.Close();
LE PROBLEME (bis)
Supposons que l'objet Account ait une propriété LongText qui contienne un gros volume de texte. Cette propriété est très rarement utilisée, et elle a été configurée en "lazy load": tant qu'on y fait pas référence elle n'est pas chargée.
La couche de présentation peut très bien faire:
IAccount a;
a = a controller returns the account>;
Response.Write(a.Name);
Response.Write(a.LongText);
Mais si l'objet est détaché de sa session, l'appel à la propriété LongText échoue parce que l'objet n'a plus la Session nécessaire pour accéder à la couche de persistence. On aura le même problème avec les associations: si un controlleur retourne un objet, on ne peut en atteindre les objets associés que si la Session est préservée, donc si l'objet n'est pas détaché.
Re: DotNetGuru vous présente son PetShop .NET
par Anonyme actif 08 Sept 2003 à 10:51
juste une petite idée comme le petshopDNG 2 est dans les starting block
il doit être possible de générer la plupart des fichiers interfaces (IAccount.cs...) et même décorator (AccountDecorator.cs...) à partir du fichier XML utilisé en entré par le DTM.
On pourrait appliquer pour cela une feuille de style XSLT à ce fichier XML. Il y a un article pas mal la dessus à cette adresse:
http://msdn.microsoft.com/msdnmag/issues/03/08/CodeGeneration/default.aspx
