Bonjour,

Les bonnes pratiques nous ont poussé à séparer nos applications en différentes couches au nom de la séparation des responsabilités. La plupart d'entre nous ont identifié :

  1. La présentation (L'affichage web/swing/forms etc..)
  2. La persistence (accès BDD)


Et entre deux la fameuse couche service qui sert de ciment entre les 2 choses. Si ces concepts de séparation sont facilement compris et acceptés, leur mise en pratique diffère fortement et c'est rien de le dire.

De mon côté, j'ai tendance à penser cette couche de service comme une API de haut niveau destinée à l'UI, offrant des méthodes simples permettant de procurer un lot de données, insérer des enregistrements, exécuter des tâches métier sous forme de transactions.
En contrepartie, les objets échangés entre la couche Ui et la couche Service sont plutôt simples car le plus souvent destinés à l'affichage, en fait ce sont souvent que de simples conteneurs de données avec assez peu de méthodes et de savoir-faire interne.

Mon approche, cependant, est je le sais, fortement critiquée notamment par Martin Fowler qui considère que c'est un antipattern du point de vue OOP

http://www.martinfowler.com/bliki/An...mainModel.html

et que la logique devrait se situer dans des objets métier qui contiendraient ainsi les données et les méthodes pour travailler dessus conformément à la programmation orientée objet.
Donc ce qui est prôné plutôt que mon approche non OO procédural d'un autre temps est donc de passer entre l'UI et le service des entités intelligentes incorporant toute la logique métier. Sur le fond je suis d'accord... Pourtant j'ai l'impression que dès qu'on a une source de données relationnelle derrière, ça coince.

Pourquoi cela coincerait en fait? Et bien car dans des applications assez poussées, modéliser une simple commande de matériel en objet indépendant nécessiterait que vous ayez accès, par exemple, aux stocks, aux pays, aux conditions de livraison du client afin d'avoir tous les éléments pour implémenter une méthode aussi simple que MaCommande.AjouteProduit( Produit p).
Alors que faites-vous? Vous chargez 250mo de données en mémoire depuis votre base SQL ou vous utilisez outrageusement le lazy loading pour que votre objet puisse se procurer ces informations à la demande?

Je suis d'accord ça marcherait certainement sur une petite application de gestion toute bête, mais au bout d'un moment comment pourrez-vous concilier la versatilité de votre objet métier qui doit soi-disant *modéliser les interactions* et les performances?
Et si vous devez modifier 1500 commandes pour marquer un retard de livraison, vous allez charger 1500 graphes pour appeler la méthode setLivraison()?

En fait j'ai un peu l'impression que cette histoire de 100% objet est un mythe, un cas d'école qui n'est réalisable que dans les applications triviales. Est-ce qu'on peut vraiment concevoir ses objets métiers en faisant abstraction du système de stockage comme on semble nous vendre dans les recueils de bonnes pratiques?

Qu'en pensez-vous?