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:

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

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s