Discussion :

[Li0303]

Bonjour,

Pour la création de notre logiciel ERP nous utilisons C# (WPF), Entity Framework (DB First, base SQL Server Pro) ainsi que le framework MVVM Light comme base de travail.

La structure de notre DB est complète, les différentes clés étrangères sont définies pour chaque table. Nos "Models" sont générés par Entity Framework.

J'aurai aimé avoir votre avis sur la meilleure manière de structurer la couche métier, avec un exemple concret. (ce type de cas se rencontrera dans de nombreux exemples)

Exemple : Mouvement de stock.

Le mouvement de stock sera utilisé dans différents modules (entrée en magasin, sortie de magasin, transfert de magasin, inventaire, expéditions, réceptions, ...) mais aura une base commune : il reçoit un paramètre "item" (reprend le code article, le type d'article, et une quantité (qui selon le cas (entrée ou sortie) sera positif ou négatif); il aura pour incidence d'aller modifier certains records (dans la table des stocks), d'en créer d'autre (table de "trace" des mouvements de stock), etc...

Donc il s'agit d'une fonction assez générique qui sera utilisée dans divers modules (Views) et donc exécutée depuis un grand nombre de View Models.

Pour éviter la redondance dans l'écriture, nous préférerions ne pas avoir à redéfinir cette fonction dans chaque View Models qui en verrait l'utilité. (Dans certains cas peut-être devront nous l'implémenter différemment mais dans la majorité des cas elle sera utilisable telle quelle).

Dans le cadre d'une architecture MVVM, où placer ce type de fonctions ?

Merci d'avance pour votre retour,

[Li0303]

Personne ?

[WDKyle]

Bonjour,

Faire hériter vos ViewModels de cette classe peut-être... ?!

[Pol63]

un truc qui doit être accessible de partout c'est un truc static, je ne vois pas ce qu'il y a à chercher ...

au lieu de suivre des patterns il suffit de réfléchir à quelles sont les solutions, les avantages et les inconvénients de chaque
notre métier n'est pas de recopier bêtement des choses

[Li0303]

un truc qui doit être accessible de partout c'est un truc static, je ne vois pas ce qu'il y a à chercher ...

au lieu de suivre des patterns il suffit de réfléchir à quelles sont les solutions, les avantages et les inconvénients de chaque
notre métier n'est pas de recopier bêtement des choses

Oui, l'objet serait static effectivement. nous avons par contre opté pour un framework MVVM en connaissances de cause. Ce que nous souhaitons seulement c'est respecter "au mieux" l'architecture MVVM sans pour autant ne voir qu'elle comme solution à nos soucis. Cet objet faisant partie de la couche "métier", il sera utilisé dans les ViewModels; mais nous trouvions un peu illogique de créer cette classe dans le dossier (espace) ViewModels puisqu'il n'en serait pas un.

Ma question était simplement (et bêtement si je puis me permettre) de savoir dans quelle "section" de l'architecture, il serait plus logique selon vous de placer cela (ou de manière plus simpliste, dans quel dossier).

Concernant pour la subtile ( ) pique concernant le fait de "réfléchir et pas bêtement recopier les choses", rien à ajouter

[Pol63]

soit tu fais un dossier pour le thème gestion des stocks, soit un dossier pour le thème fonctions communes
et tu peux changer d'avis après dans le pire des cas