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 ?