La place des Business Objects dans le MVP

Où doit-on placer nos composants d’affaires (i.e Business Objects) lorsque l’on utilise les designs patterns du genre Model-View-Presenter (MVP) ou Model-View-Controller (MVC) ?

C’est une bonne question et je la retrouve régulièrement dans les projets auxquels j’ai travaillé.

Mais avant de poursuivre, voici une conversation forte intéressante que j’ai observée sur twitter il y a quelque temps entre Robert « Uncle Bob » Martin et Martin Fowler à ce sujet:

@unclebobmartin	Views should have no knowledge of business objects. Presenters should create data structures from business objects & views should use them.
@martinfowler	@unclebobmartin disgree. It’s both traditional and effective for views to see domain objects
@RonJeffries	@unclebobmartin i’d wanna see one or more examples showing why views shouldn’t see domain objects but instead … what, « views « of them?
@unclebobmartin	@martinfowler The problem is that views become coupled to business logic. Changes to BOs imply changes to views.
@martinfowler	@unclebobmartin I think the relationships between view, model and other elements is too context-specific for a general rule
@GBGames	@unclebobmartin @martinfowler To be clear, I know MVC, but it seems there’s debate about what the V knows about the M?
@martinfowler	@GBGames @unclebobmartin There are many forms of MVC with different trade-offs. I said more at http://martinfowler.com/eaaDev/uiArchs.html
@unclebobmartin	@peter_bugge BOs change for reasons of business logic. Views need not be affected.
@unclebobmartin	@sebasmonia A change to the BO will often cause change to presentation logic, but hopefully not to the views.
@unclebobmartin	An object has private state and public methods. A data structure has public data and no methods. Getters and setters make data public.
@unclebobmartin	@MahasenBandara Views are concrete. Models are abstract. Views should depend on Models.
@unclebobmartin	Business interactions are also business objects. Controllers should invoke interactions not _be_ interactions.
	…

En résumé, Uncle Bob mentionne que pour éviter le couplage, le presenter devrait se refaire de nouveaux objets et les passer à la vue. Martin Fowler nuance un peu le tout en mentionnant que ce n’est pas vrai tout le temps et que cela dépend du contexte.

Le fait de se refaire de nouveaux objets pour la vue peut amener certains problèmes. Exemple, j’ai vu très souvent ce genre de code qui, pour moi, est un beau cas de duplication:

 public ViewObject ConvertObject(BusinessObject objectFromModel)
        {
            var viewObject = new ViewObject() ;
            viewObject.Name = objectFromModel.Name;
            viewObject.Adress = objectFromModel.Adress;
            viewObject.PhoneNumber = objectFromModel.PhoneNumber;
            viewObject.City = objectFromModel.City;

            return viewObject;
        }
    }

Hmm, redondant n’est-ca pas ?

Si les objets sont pratiquement semblables, je suis d’accord avec le point de Martin Fowler et que ce genre d’objets peut être visible au niveau de la vue.

Par contre, s’il y a quelques différences ou des champs non utiles qui sont tout de même transférés à la vue, je crois qu’il vaut mieux y aller avec de nouveaux objets comme le mentionne Uncle Bob.

Bref, la règle à suivre selon moi est de toujours voir selon les besoins du contexte.

Et vous, qu’est-ce que vous faites dans ce cas avec les Business Objects ?

Mon expérience au Code Retreat

Le 21 mai dernier, moi et deux autres collègues (Félix-Antoine Bourbonnais et Amélie Turgeon) avons organisé le premier Code Retreat à Québec. Tout cela a commencé en début février lorsque le nouveau conseil d’administration de la communauté Agile de Québec s’est réuni.

Lors d’un tour de table, il a été suggéré de tenter d’organiser cet événement. Je trouvais qu’il n’y avait pas assez d’événements de ce genre pour les programmeurs. En particulier des événements qui ne parlent pas de produit d’un vendeur ni d’une technologie particulière. Juste du code orienté-objet sans égards à un langage particulier.

Comme nous n’avions jamais fait ce genre d’événement, il nous fallait un facilitateur de calibre et qui en avait fait beaucoup auparavant: Corey Haines. Ce dernier habite Chicago et le faire venir ici comporte certains frais, mais rien de trop astronomique. Donc, on s’est rendu compte que c’était possible de le faire venir. Dans notre planification, l’aide des commanditaires serait aussi importante et permettrait de définir le prix d’entrée, le lieu et la nourriture et les rafraichissements servis aux participants durant la journée.

Donc, au fil des mois tout s’est tranquillement mis en place pour réaliser l’événement qui fut un bon succès selon moi. Une grande majorité des participants ont apprécié. On a aussi pu noter certains aspects qui seront à améliorer la prochaine fois que l’on réalisera cet événement. Car nous avons bien l’attention d’en refaire un. Mais avec l’Agile Tour 2011 qui s’en vient cet automne, c’est bien possible que cela ait lieu qu’en 2012.

Aussi, organiser tout cela nous a permis de tester ou d’approfondir certaines technologies qui pourraient nous être utiles dans le futur :

WordPress: Nous avons fait un blogue pour contenir toute l’info de l’événement.
Eventbrite: Pour la gestion des inscriptions
Google Documents: Pour l’échange de documents entre les organisateurs
Survey Monkey: Définition et compilation des sondages d’appréciation de l’événement.

Au niveau du contenu de l’événement, j’ai aussi bien adoré. J’ai été surpris du nombre de personnes qui n’avaient jamais vraiment pratiqué le TDD avant. Mais c’est le but de ce genre d’événement, donner du temps pour pratiquer des techniques et langages qu’on n’a pas l’occasion de pratiquer au travail. L’apport de Corey Haines a aussi été excellent. Cela nous guidera lors des prochains Code Retreat. Car ce sera nous de jouer le rôle de facilitateurs la prochaine fois. J’ai bien aimé aussi mes différentes sessions de pairage. J’ai pu me remettre au C# (car je fais du VB.Net habituellement), voir un peu de Ruby à l’œuvre et appris quelques trucs ici et là. J’ai aussi montré l’outil Resharper à quelques-uns et du C# à un gars de Java. Bref, it was a blast !

En résumé, je suis bien content de voir qu’à partir d’une idée, et entouré de bonnes personnes, on peut voir un projet se réaliser. Il ne faut pas toujours avoir peur de commencer des choses, mais il faut plutôt oser le faire. On y découvre alors plein de choses…

Références :

Critique du livre: The Passionate Programmer

Êtes-vous passionnés par votre travail ?

Je me suis intéressé à ce livre un peu par curiosité et je voulais voir ce qu’il pouvait apporter à ma carrière. Autrefois intitulé My job went to India: 52 ways to save your job dans sa première édition, le livre a changé de nom pour sortit un peu du titre controversé et bien refléter son sujet principal: comment avoir une carrière remarquable en tant que programmeur. L’auteur Chad Fowler est développeur connu au niveau international. Il travaille principalement avec le langage Ruby et le Framework Ruby on Rails.

Le livre est composé de 53 conseils de carrière divisés en 5 sections dont voici leurs descriptions:

Choisir son marché : L’importance de bien choisir dans quelles technologies et quel domaine d’affaires on veut évoluer. Ne pas se limiter à une seule technologie et bien balancer les risques potentiels.
Investir dans son produit : Mise à part la programmation, il est aussi important de bien connaître son domaine d’affaires. Si on ne connait pas trop certaines notions, se trouver un mentor. Si on veut voir si on connaître bien son affaire, essayer de l’enseigner à quelqu’un d’autre. Et ne pas oublier de pratiquer, pratiquer et pratiquer.
Exécution : Se rappeler régulièrement pour qui on travaille et s’assurer d’apporter de la valeur à l’entreprise. Noter ses bons coups et savoir comment gérer ses erreurs sont aussi important.
Marketing, pas seulement pour les cadres : Les perceptions sont importantes, c’est d’ailleurs le facteur principal dans les évaluations de rendement. Être présent et communicatif. Parler le langage de nos interlocuteurs.
Maintenir son expertise : Nous sommes déjà obsolètes ! C’est donc nécessaire de faire son plan de carrière, de surveiller les tendances et de s’évaluer régulièrement

J’ai particulièrement aimé les sections qui parlaient des notions de Généralistes et de Spécialistes. L’auteur raconte qu’il est important d’être les deux. Je m’explique:

Être un généraliste: L’idée est ne pas être seulement un programmeur. Si l’opportunité se présente, ne pas hésiter à faire aussi de l’analyse, de l’architecture, de la charge de projet ou administrateur de base de données. L’idée est d’être utile à l’équipe, peu importe les tâches. C’est un peu la même chose au niveau de la technologie. Il faudrait normalement que nos habiletés transcendent les différentes infrastructures. Si on maîtrise bien une plateforme, ne pas hésiter à approfondir une autre.
Être un spécialiste: Bien connaître à fond un type de technologie est important. On ne parle pas ici de tout connaître, mais d’avoir une bonne profondeur pour connaître environ 80 % des situations qui pourraient se présenter au programmeur. Exemple: Si vous êtes un spécialiste .NET, vous n’avez pas d’excuses de ne pas connaître tout sauf du .Net. Il faut aussi savoir comment redémarrer un serveur IIS, faire l’installation d’un gestionnaire de code source ou corriger des problèmes de performance.

En conclusion, j’ai beaucoup aimé ce livre et d’ailleurs cela m’a pris seulement deux semaines à livre. Je le recommande à tous ceux œuvrant dans le domaine de la programmation, de près ou de loin. Les conseils de Chad Fowler, bien que pas nécessairement applicable pour tous, sont intéressants. On voit aussi à travers le livre ce qu’ont vécu l’auteur et les choix de carrière qu’il a du faire et pourquoi il les a faits. Bref, soyez passionné et remarquable !

Point négatif: On parle beaucoup du contexte américain et des emplois volatiles surtout en crise économique. Cela ne s’applique pas trop au Québec où l’on manque d’informaticiens un peu partout.

Mes points clefs:

Investir dans sa carrière est important. Il ne faut pas attendre que son employeur le fasse.
Être un généraliste et un spécialiste en même temps.
Bien connaître le domaine d’affaire de son employeur est un atout important.

Références :

TFS est ouvert aux vieilles technos

Je regardais récemment le scénario d’intégrer du code VB6 dans le gestionnaire de code source Team Foundation Server (TFS) 2008, histoire de faire un premier pas vers une conversion à .NET. C’est en fouinant un peu que j’ai découvert l’existence du Visual Studio Team System 2008 Team Foundation Server MSSCCI Provider

Ce petit provider de Microsoft s’avère très utile si vous avez de vielles applications et que vous voulez tout regrouper sous un même toit, comme avec TFS. On peut ainsi dire un beau bye-bye à Visual SourceSafe.

L’outil permet d’utiliser TFS comme gestionnaire de code source pour des outils de développement un peu vieillot tel que VB6 ou Visual FoxPro. Il marche même avec PL/SQL après l’ajout d’un petit plug-in:

Du côté de VB6, tout marche très bien et les menus; ils sont pratiquement les même qu’avec Visual Source Safe (VSS):

On peut aussi changer de gestionnaire de code source au besoin grâce au programme suivant qui est installé avec le provider:

Une fois notre option choisie, on verra le bon gestionnaire de code source à la prochaine ouverture de notre outil de développement.

On peut donc ouvrir un projet VB6 sous VSS, changer le gestionnaire de code source et ouvrir une deuxième instance de VB6 qui utilisera TFS.

Points à retenir:

L’historique de VSS ne se copie pas dans TFS. À moins de faire une conversion, mais la procédure semble plus complexe qu’une simple copie des fichiers.
Le concept de fichiers partagés de VSS n’existe pas dans TFS. Si c’est utilisé, prévoir du temps pour réarranger le code.
La recherche dans TFS 2008 ne peut aller jusqu’au contenu des fichiers. On ne peut que chercher les titres des fichiers (!). Je ne sais pas si cette lacune est corrigée dans TFS2010 par contre.

Donc, ne jeter pas VSS aux poubelles trop vite. Il pourrait servir pour des recherches et des consultations de l’historique.

Pourquoi je n’aime pas les générateurs de code ?

Je n’ai jamais vraiment beaucoup aimé les générateurs de code.

Vous savez, le genre d’outils qui peut vous générer des centaines et parfois même des milliers de lignes de code avec simplement quelques paramètres ?

Dans cet article, je vais discuter des points positifs et négatifs quant à l’utilisation d’outils de générateurs de code. Des exemples de différents générateurs seront aussi décrits.

On mentionne souvent que ces outils nous font économiser des centaines d’heures et aide à avoir du code plus standard, je pense par contre qu’à moyen et long terme, il peut y avoir certains effets négatifs.

Comme par exemple :

Nuit à l’apprentissage: C’est le point le plus important d’après moi. Le simple fait que de ne pas avoir touché à une partie du code, nous rend vulnérable par rapport celle-ci. Aussi, il est important de bien comprendre un système informatique dans son ensemble et non seulement les parties du code qui n’ont pas été générées. Faut aussi savoir que tel générateur ne sera pas disponible dans un autre projet… Exemple: un générateur de code se charge de produire les contrats de services et de données en WCF. Il se charge de bien créer les classes et de mettre les bons « tags » relatifs à WCF. Dans ce cas, on ne peut pas dire que nous avons gagné de l’expérience avec WCF. Si on arrive dans un autre mandat ou projet et que le générateur n’existe pas, il nous faudra approfondir WCF car finalement, on ne le connaît pas vraiment malgré son utilisation dans un précédent projet.

Difficultés lors de la recherche d’erreurs : Les générateurs de code produisent en général du code un peu obscur et difficile à lire. Si une erreur se produit dans cette partie du code, la recherche peut s’avérer longue et douloureuse.

Pour une simple correction, on a souvent pas le choix d’utiliser le générateur de code: C’est en général non-productif de devoir refaire l’exécution du générateur pour faire un petit changement, comme renommer une méthode par exemple ou changer de type une propriété. Pour ces gestes, c’est tellement plus facile et rapide d’y aller manuellement…

Bien que j’aie déjà utilisé certains de ces outils, je peux avouer qu’ils sont parfois efficaces et, probablement, valent la peine d’être utilisé selon le contexte. Dans certains environnements avec des dizaines de programmeurs, on n’a pas trop le choix de standardiser certaines parties du code malgré les inconvénients. Bref, je crois que l’idéal est d’avoir une bonne balance entre productivité à court terme et l’apprentissage à long-terme.

Voici quelques-unes de mes expériences avec les générateurs de code:

Bonnes:

LINQ to SQL: Le code généré à partir de tables SQL Server n’est pas trop gros. C’est certain qu’il n’est pas très beau non plus, mais c’est assez facile de se créer une classe « extended » pour y ajouter des options particulière, comme une chaîne de connexion qui peut changer selon certaines conditions. Mais dans ce cas, le gain se fait surtout par l’utilisation directe de LINQ pour lire et modifier nos classes SQL. Le code que l’on créé ainsi manuellement est beaucoup plus lisible et simple avec LINQ.

Resharper: La génération de code dans Resharper se charge surtout de petits bouts de code qui seront intégrés à notre classe. Après cela, on les manipule comme on veut. Voyez ici les exemples .

Négatives:

Smart Client Software Factory: Il y a une bonne volonté ici de faire des outils pour générer nos vues, contrôleurs et autres structures nécessaire au pattern MVP-C. Par contre cela en résulte en un nombre assez nombreux d’événements. Lorsqu’il faut faire du débogage, on ne se sait plus trop ou donner de la tête lorsque cela saute d’un événement à l’autre.

CodeSmith : J’ai déjà utilisé cet outil pour générer une couche d’accès aux données dans un précédant projet. Je trouvais terrifiant de voir des milliers de lignes de codes produite pour simple une table avec une dizaine de colonne seulement. Par chance que les erreurs ne s’y trouvaient pas souvent. Noter aussi que CodeSmith a d’autres outils que je n’ai pas essayé et qui sont probablement intéressant malgré tout.

L’outil « Add Service Reference » de Visual Studio pour WCF: Je n’aime pas cette option qui se fait un peu trop facilement avec un clic droit de la souris. Le gros problème c’est que le fichier de configuration est rempli plein d’options sélectionnés dont plusieurs ne sont pas utile. Aussi, c’est un peu embêtant si on ajoute un deuxième service en référence dans le même projet. J’aime beaucoup mieux la méthode manuelle tel que décrit dans l’article WCF the Manual Way…the Right Way

Et vous, que pensez-vous des générateurs de code ?

Coder son architecture

Est-ce que vous connaissez le blogue suivant :

Si oui, tant mieux 🙂

Sinon, je vous le conseille fortement, surtout si l’architecture logicielle vous intéresse. D’ailleurs on le retrouve parmi ma liste de blogue que je lis disponible dans la colonne droite de ce blogue.

L’auteur du blogue, Simon Brown, a les mêmes opinions que moi par rapport au rôle de l’architecte et des programmeurs. Soit :

Un architecte logiciel ne devrait jamais arrêter de coder afin d’être toujours conscient de ce qui se passe à ce niveau et ainsi éviter de se retrouver avec le syndrome de la tour d’ivoire.
De la même manière, les programmeurs devraient avoir la vision globale de l’architecture et ne pas seulement se concentrer sur leur bout de code.

Les grandes lignes de ce blogue se retrouvent dans la liste suivante (Je vous recommande fortement de les consulter !!!) :

What is software architecture?: This category covers all of the basics such as what software architecture is all about and why it’s important.
What is the role of a software architect?: This is probably the largest category on the site where you’ll find lots of discussion about what software architects (should, in our opinion) do.
How do you define software architecture?: This category is about putting software architecture into practice, where you’ll find articles about what drives architecture, technology selection, dealing with non-functional requirements and so on.
How do you share software architecture?: Having a software architecture is only part of the puzzle and this category is all about collaborating, documenting and sharing it.
How do you deliver software architecture?: The final category is about delivering the architecture; covering aspects such as process, methodology, evaluating and testing architectures.

Aussi, d’autres articles intéressants:

Strategy rather than code: What *is* enterprise architecture and is it the next step for your software career?
You don’t need a UML tool: A short essay about why you don’t need a UML tool to do software architecture.
Start with the big picture: This essay talks about the levels of detail you might go into when you’re defining a software system.
The code doesn’t tell the whole story: The code might be the ultimate deliverable, but it isn’t everything.
Software architecture is a platform for conversation: An essay that explains why you should talk to people during the software architecture definition process.
The Other Interface: Why you shouldn’t ignore logging in your software.
Software architecture document guidelines: Software documentation should be complementary to the code and describe what the code itself doesn’t. This essay provides some guidelines as to what you might want to include.