[Débutant] Réalisation d'une ERP [Résolu]

[sam1989]

Bonjour,
Dans le cadre de mon stage, je dois réaliser, seul, une ERP en WPF avec une base de données MySQL. Mais étant toujours étudiant et n'ayant jamais réalisé de vraies ERP professionnelles (les petits projets d'école sont très loin de la complexité de mon projet actuel), je me demandais si j'ai fait les bons choix et j'aimerai donc avoir des conseils et/ou des remarques :

- J'utilise le patern MVVM en me servant de MVVM Light (je suis encore loin de savoir maîtriser ce patern mais j'espère y arriver très vite)
- J'utilise Entity Framework pour ma couche d'accès aux données et la création de mes entités.
- J'aimerai utiliser un framework de test unitaire une fois que j'aurai compris comment m'en servir (je pense pour l'instant à NUnit, est-ce le bon choix ?)
- J'essaie de mettre en place un système de navigation pour avoir qu'une seule fenêtre et afficher une page à l'intérieur de cette fenêtre (j'y arrive en WPF simple mais pas encore en MVVM).
- Dans les nombreux tutos que j'ai trouvé sur MVVM, je vois souvent le terme "inverseur de contrôle" mais j'ai encore du mal à comprendre cette notion. Est-ce vraiment nécessaire pour réaliser une application en MVVM ?

D'avance merci.

[marcusien]

On ne peut guère résumer la réalisation d'un ERP en quelques lignes mais ton approche est pas mal.

Cependant cela va dépendre énormément de ton besoin derrière. Donc sans éléments supplémentaires on peut difficilement te répondre.

Concernant l'inversion de contrôle (autrement appelé IOC), cela te permet d'être beaucoup plus souple et d'apporter énormément d'abstraction. C'est vraiment essentiel si tu souhaites faire des projets avec des technos différentes (web, WPF, Winforms...). Tu peux regarder des tutos tu trouveras des choses intéressantes à ce sujet normalement. En gros cela consiste à passer par des interfaces voir des classes abstraites pour faire tes développements. Ainsi tu n'utilises que très rarement tes classes concrètes durant tes développements dans les couches métiers et ViewModels, mais tu préfèreras utiliser tes interfaces
sans IOC

Code c# :

MyObject monObjet = myDataContext.GetMonObjet();

avec IOC

Code c# :

1
2
IMyObject monObjet = myDataContext.GetMonObjet();
//GetMonObjet renverra bien entendu un IMyObject

Concernant les tests unitaires, tu peux utiliser les tests unitaires intégrés à Visual Studio. Cependant sur une version Express par exemple ils ne sont pas présents donc effectivement ta solution est une bonne alternative (même si je ne l'ai jamais utilisé)

[sfxzeus]

Pour ce qui est de la navigation en MVVM, il te faudra utiliser des datatemplate avec un contentPresenter.

Tu fais descendre tout tes viewModel du même ancêtre.

Le Content du ContentPresenter étant binder au viewModel que tu veux afficher il sélectionnera la vue a afficher.

Exemple :

Code xaml :

1
2
3
4
5
6
7
8
9
10
11
 
<ContentPresenter Content="{Binding DetailViewModel}">
            <ContentPresenter.Resources>
                <DataTemplate DataType="{x:Type ViewModel:ViewModel1}">
                    <View:View1/>
                </DataTemplate>
                <DataTemplate DataType="{x:Type ViewModel:ViewModel2}">
                    <View:View2/>
                </DataTemplate>
            </ContentPresenter.Resources>
</ContentPresenter>

J'en avais parlé dans ce précédent post avec une micro démo

[sam1989]

Merci pour vos réponses =)

Envoyé par marcusien

Concernant l'inversion de contrôle (autrement appelé IOC), cela te permet d'être beaucoup plus souple et d'apporter énormément d'abstraction. C'est vraiment essentiel si tu souhaites faire des projets avec des technos différentes (web, WPF, Winforms...). Tu peux regarder des tutos tu trouveras des choses intéressantes à ce sujet normalement. En gros cela consiste à passer par des interfaces voir des classes abstraites pour faire tes développements. Ainsi tu n'utilises que très rarement tes classes concrètes durant tes développements dans les couches métiers et ViewModels, mais tu préfèreras utiliser tes interfaces

Donc si j'ai bien compris, IOC consiste à implémenter des interfaces pour ne pas déclarer implicitement un objet de la classe X dans la classe Y et réduire les dépendances de la classe Y par rapport à la classe X, c'est ça ?

Envoyé par sfxzeus

Pour ce qui est de la navigation en MVVM, il te faudra utiliser des datatemplate avec un contentPresenter.

Tu fais descendre tout tes viewModel du même ancêtre.

Le Content du ContentPresenter étant binder au viewModel que tu veux afficher il sélectionnera la vue a afficher.

J'en avais parlé dans ce précédent post avec une micro démo

Merci pour ta démo, je suis en train de la regarder et je crois que c'est tout à fait ce que je cherchais =)


J'ai encore une question : lorsque je mets à jour ma base de données, est-ce que je peux mettre à jour mon modèle généré par Entity Framework ? Ou je suis à chaque fois obligé d'en recréer un nouveau ? (Lorsque je fais un clique-droit sur le model et que je clique sur actualiser, il ne récupère pas les modifications faites sur la base de données).

[marcusien]

Donc si j'ai bien compris, IOC consiste à implémenter des interfaces pour ne pas déclarer implicitement un objet de la classe X dans la classe Y et réduire les dépendances de la classe Y par rapport à la classe X, c'est ça ?

J'aime pas trop dire "consiste à implémenter des interfaces" dans ce cas là, car concrètement, implémenter des interfaces, c'est ... implémenter une interface au sein d'une classe concrète.

l'IOC consiste simplement à utiliser le plus possible tes objets concret par le biais de tes interfaces.

Comme tu l'as dit, le but consiste effectivement à réduire au maximum les dépendances. Et pour ce faire, comme tu l'as dit à peu près correctement, on utilise dans son code les interfaces plutôt que les classes concrètes.

J'ai encore une question : lorsque je mets à jour ma base de données, est-ce que je peux mettre à jour mon modèle généré par Entity Framework ? Ou je suis à chaque fois obligé d'en recréer un nouveau ? (Lorsque je fais un clique-droit sur le model et que je clique sur actualiser, il ne récupère pas les modifications faites sur la base de données).

Vu ta question je suppose que tu utilises l'approche Entity Framework Database First.
Effectivement si tu mets à jour ta base de données, tu peux aller dans ton fichier edmx et mettre à jour le modèle. Par contre au bout d'un moment, si tu fais beaucoup de modifications, notamment des suppressions de champs (les ajouts ne posent pas de souci), Entity Framework ne supprimera pas ces champs que tu as supprimé dans le modèle. Donc soit tu les supprimes manuellement après avoir rafraichit, soit tu refais un modèle en entier.
Dans le cadre d'un projet en équipe il va de soi que tu ne vas pas supprimer ton edmx dès que tu fais un modification ;-)

[sam1989]

Merci pour ta réponse marcusien

J'ai encore une petite question en ce qui concerne l'EF :p
est-ce mieux de créer un singleton pour accéder aux données ou alors instancier un objet de ma classe généré par EF dans un using et effectuer les opération à l’intérieur comme ceci ? :

Code :

1
2
3
4
5
6
7
8
9
 
public List<Client> GetAll ()
{
     var myClientList = new List<Client>();
     using (MyDataContext = new MyDataBaseEntitites())
     {
           myClientList = MyDataContextEntities.clients.ToList();
     }
}

[micka132]

Concernant la BDD un ERP ne doit posséder que quelques tables propre à lui et intégrer de nouvelles table qu'il ne doit pas connaitre. Du coup est ce que l'approche EF est raisonnable? Enfin du moins dans son utilisation premiere (donc 99% des tutorials) où tu dois connaitre le modèle, et recompiler à chaque fois?

[sam1989]

Envoyé par micka132

Concernant la BDD un ERP ne doit posséder que quelques tables propre à lui et intégrer de nouvelles table qu'il ne doit pas connaitre. Du coup est ce que l'approche EF est raisonnable? Enfin du moins dans son utilisation premiere (donc 99% des tutorials) où tu dois connaitre le modèle, et recompiler à chaque fois?

C'est la première fois que je réalise un ERP (et en plus je suis seul sur le projet donc ce n'est pas facile pour moi de comprendre toutes les notions des ERP).

Si mon ERP ne connait que quelques tables, comment pourrais-je faire toutes les opérations sur ma base de données ? (Appeler des procédures stockées ?)

Et si l'approche EF n'est pas bonne, je dois la remplacer par un autre framework ou tout réaliser à la main ?

[Bluedeep]

Envoyé par micka132

Concernant la BDD un ERP ne doit posséder que quelques tables propre à lui et intégrer de nouvelles table qu'il ne doit pas connaitre. Du coup est ce que l'approche EF est raisonnable? Enfin du moins dans son utilisation premiere (donc 99% des tutorials) où tu dois connaitre le modèle, et recompiler à chaque fois?

Utiliser EF pour travailler avec un modèle de données dynamique me semble en effet une approche quelque peu osée.

[sam1989]

Envoyé par Bluedeep

Utiliser EF pour travailler avec un modèle de données dynamique me semble en effet une approche quelque peu osée.

Quelle approche dois-je adopter alors ?

[micka132]

Je ne sais pas . En fait ca va surement dépendre de la compléxité des intéractions de chaque module, et si un module est extensible ou pas.
Il me semble que sur dvp il y a un bien gros tutoriel sur le mécanisme d'un ERP, mais je n'ai pas le temps de le trouver.

En tout cas pour moi il y a beaucoup trop de paramètre en prendre en compte pour avoir une réponse simple et clair sur un forum. Je ne vais pas te dire que EF n'est pas le bon outil, c'est juste que du peu de connaissance que j'en ai, il me semble innaproprié.

Pai ailleurs si je m'imagine devoir faire des requettes dynamiques je me vois bien utiliser un fichier de description (xml), et c'est justement ce qu'est EF.
Le problème c'est de pouvoir s'en servir autrement que comme les 99% tutorial qu'il y avait à une époque (2010) lorsque je m'y était interressé. Notamment creer les objets à la volés.
Reste que tu ne connaitras pas ton objet à la programmation, et pour le coup on se demande l'interêt de l'ORM .

Des versions sont sorties depuis, mais j'imagine que les documents que tu vas pouvoir trouver sont toujours destinés à une utilisation simple et rapide de EF. Or pour ton problème c'est loin d'être le cas.

[sam1989]

Envoyé par micka132

Je ne sais pas . En fait ca va surement dépendre de la compléxité des intéractions de chaque module, et si un module est extensible ou pas.
Il me semble que sur dvp il y a un bien gros tutoriel sur le mécanisme d'un ERP, mais je n'ai pas le temps de le trouver.

En tout cas pour moi il y a beaucoup trop de paramètre en prendre en compte pour avoir une réponse simple et clair sur un forum. Je ne vais pas te dire que EF n'est pas le bon outil, c'est juste que du peu de connaissance que j'en ai, il me semble innaproprié.

Pai ailleurs si je m'imagine devoir faire des requettes dynamiques je me vois bien utiliser un fichier de description (xml), et c'est justement ce qu'est EF.
Le problème c'est de pouvoir s'en servir autrement que comme les 99% tutorial qu'il y avait à une époque (2010) lorsque je m'y était interressé. Notamment creer les objets à la volés.
Reste que tu ne connaitras pas ton objet à la programmation, et pour le coup on se demande l'interêt de l'ORM .

Des versions sont sorties depuis, mais j'imagine que les documents que tu vas pouvoir trouver sont toujours destinés à une utilisation simple et rapide de EF. Or pour ton problème c'est loin d'être le cas.

Merci pour ta réponse micka132

Je viens de tomber sur ce tuto et je pense que ce genre de projet est vraiment pas à ma porter x)
Je pense que j'ai plus de chance de gagner au Loto que de réaliser un vrai ERP en partant de zéro, seul, en étant stagiaire et en moins de 12 semaines...
Donc je pense que je vais plutôt partir sur une simple application construite en 3 couches et pouvant dialoguer avec la base de données

Je vais la réaliser en WPF simple pour l'instant en utilisant quand même l'EF puis je verrai par la suite (si j'ai le temps) de complexifier le projet.

Ps : c'est une petite entreprise de 5 personnes donc je pense que ce genre de projet leur suffira amplement ... ensuite si ils s’agrandissent et qu'ils ont les moyens, ils pourront toujours invertir dans un vrai ERP.

[marcusien]

Concernant EF, tout dépend de l'approche que vous utilisez.

L'approche la plus dynamique et qui tend à être la plus utilisée (notamment parce que la plupart du temps, il n'y a pas de vrais admins bdd, mais des développeurs qui s'improvisent ce poste) c'est l'approche CODE FIRST.

Et en Code First, tu peux dynamiser tout ça.

L'approche par module d'un ERP ne gêne absolument pas, parce que même si ta base est complète, seuls tes modules utiliseront ces tables. Tu peux même imaginer des modules qui vont aller générer dynamiquement des tables dans ton modèle à leur incorporation dans ton appli par MEF ou autres.

Je te dis ça car on avait développé un gros ERP dans ma boite à 3 développeurs où on utilisait EF Code First (beta ^^) même avec du OData, de la modularité etc. EF a fait l'affaire.
Après pour un petit projet comme toi c'est peut être pas forcément évident à mettre en place.


Sinon pour ta question concernant le Singleton ou le using, ça dépend vraiment de ton usage.
Si tu utilises un Context pour alimenter un écran complexe, tu passeras sûrement par une solution genre singleton.
Si c'est pour un traitement très localisé et court, tu peux utiliser le using.

[sam1989]

Envoyé par marcusien

Concernant EF, tout dépend de l'approche que vous utilisez.

L'approche la plus dynamique et qui tend à être la plus utilisée (notamment parce que la plupart du temps, il n'y a pas de vrais admins bdd, mais des développeurs qui s'improvisent ce poste) c'est l'approche CODE FIRST.

Et en Code First, tu peux dynamiser tout ça.

L'approche par module d'un ERP ne gêne absolument pas, parce que même si ta base est complète, seuls tes modules utiliseront ces tables. Tu peux même imaginer des modules qui vont aller générer dynamiquement des tables dans ton modèle à leur incorporation dans ton appli par MEF ou autres.

Je te dis ça car on avait développé un gros ERP dans ma boite à 3 développeurs où on utilisait EF Code First (beta ^^) même avec du OData, de la modularité etc. EF a fait l'affaire.
Après pour un petit projet comme toi c'est peut être pas forcément évident à mettre en place.


Sinon pour ta question concernant le Singleton ou le using, ça dépend vraiment de ton usage.
Si tu utilises un Context pour alimenter un écran complexe, tu passeras sûrement par une solution genre singleton.
Si c'est pour un traitement très localisé et court, tu peux utiliser le using.

Merci marcusion pour ta réponse =)
J'ai été voir ce tuto pour l'approche code first et ça m'a l'air bien intéressant comme approche. Le détail qui me dérange le plus est qu'il génère la base de donnée à partir du code et que moi, j'ai déjà créé ma base de donnée ^^" (étant donné que j'ai 35 tables, je préfère ne pas avoir à recommencer toute sa création vu le temps qu'il me reste). Mais la couche DTO a l'air bien sympa pour s'affranchir de la base de données et ne pas avoir besoin de redéfinir à chaque fois un nouveau model lorsque je modifie ma base de données x)
Je pense que je vais l'intégrer à mon projet, ça me permettra de me concentrer plus sur le code et d'être moins dépendant de ma base de données =)

[marcusien]

Je trouve quelques avantages non négligeable à cette approche. Pour un dévelooppeur c'est super simple, tu as juste de la gestion d'attributs, tu as une bonne maitrise de ce qui est généré en général, avec un package nugget tu peux visualiser graphiquement ton modèle (comme avec l'approche model first).
Et un des derniers avantages et non des moindres : TFS ! Au moins si quelqu'un touche au modèle, tu peux suivre l'évolution et éventuellement revenir en arrière. Ce n'est vraiment pas négligeable à mon sens.

Pour tes 35 tables, ça ne devrait pas te poser trop de soucis. Créer une classe et des relations c'est rapide.
Pis pour la déclaration de chacune de tes classes dans le DataContext, tu peux le faire en T4 c'est juste génial ^^

[sam1989]

Envoyé par marcusien

Je trouve quelques avantages non négligeable à cette approche. Pour un dévelooppeur c'est super simple, tu as juste de la gestion d'attributs, tu as une bonne maitrise de ce qui est généré en général, avec un package nugget tu peux visualiser graphiquement ton modèle (comme avec l'approche model first).
Et un des derniers avantages et non des moindres : TFS ! Au moins si quelqu'un touche au modèle, tu peux suivre l'évolution et éventuellement revenir en arrière. Ce n'est vraiment pas négligeable à mon sens.

Pour tes 35 tables, ça ne devrait pas te poser trop de soucis. Créer une classe et des relations c'est rapide.
Pis pour la déclaration de chacune de tes classes dans le DataContext, tu peux le faire en T4 c'est juste génial ^^

Merci pour ta rapidité ^^
Je pense que je vais étudier ta proposition (je viens de me renseigner vite fait sur T4 et ça a l'air sympa).
Pour ce qui est du gestionnaire de source, je n'utilise pas TFS mais git (il me semble que TFS est mieux adapté pour les projets d'équipe mais vu que je suis seul, j'ai opté pour git ^^).

Sinon je viens tout juste d'y penser mais est-ce qu'il peut y avoir un risque de conflit avec EF lorsque 2 utilisateurs tentent par exemple de rajouter un nouveau client en même temps ?

[marcusien]

Sinon je viens tout juste d'y penser mais est-ce qu'il peut y avoir un risque de conflit avec EF lorsque 2 utilisateurs tentent par exemple de rajouter un nouveau client en même temps ?

Je pense que tu veux parler des accès concurrentiels. Ca se gère avec des attributs sur tes propriétés. Je te conseille ces liens
http://msdn.microsoft.com/en-us/data/gg193958.aspx
http://www.dotnetrangers.net/2011/10...cy-management/
Je ne sais plus si tu peux choisir entre Optimistic ou Pessimistic. A toi de te renseigner à ce sujet.

Concernant le T4, c'est un peu du hard-coding. Je te conseille le package nugget T4 tangible. C'est un peu déroutant la première heure mais c'est extrèmement puissant (EF Code First c'est du T4 ^^). C'est super quand tu utilises des architectures complexes où tu dois répliquer ton modèle (par exemple une archi du style EF Code First -> WCF Data Services -> client MVVM (avec la couche Model))

Pour ce qui est du gestionnaire de source, je n'utilise pas TFS mais git (il me semble que TFS est mieux adapté pour les projets d'équipe mais vu que je suis seul, j'ai opté pour git ^^).

Même pour travailler tout seul TFS est très bien En plus maintenant il y a Team Foundation Services qui est gratuit en dessous de 5 users.
Mais ma remarque portait surtout sur le fait que tu peux faire du versionning, peu importe le contrôleur de code source utilisé

[sam1989]

Envoyé par marcusien

Je pense que tu veux parler des accès concurrentiels. Ca se gère avec des attributs sur tes propriétés. Je te conseille ces liens
http://msdn.microsoft.com/en-us/data/gg193958.aspx
http://www.dotnetrangers.net/2011/10...cy-management/
Je ne sais plus si tu peux choisir entre Optimistic ou Pessimistic. A toi de te renseigner à ce sujet.

Concernant le T4, c'est un peu du hard-coding. Je te conseille le package nugget T4 tangible. C'est un peu déroutant la première heure mais c'est extrèmement puissant (EF Code First c'est du T4 ^^). C'est super quand tu utilises des architectures complexes où tu dois répliquer ton modèle (par exemple une archi du style EF Code First -> WCF Data Services -> client MVVM (avec la couche Model))


Même pour travailler tout seul TFS est très bien En plus maintenant il y a Team Foundation Services qui est gratuit en dessous de 5 users.
Mais ma remarque portait surtout sur le fait que tu peux faire du versionning, peu importe le contrôleur de code source utilisé

Merci, je regarde ça tout suite

[sam1989]

Envoyé par marcusien

Je pense que tu veux parler des accès concurrentiels. Ca se gère avec des attributs sur tes propriétés. Je te conseille ces liens
http://msdn.microsoft.com/en-us/data/gg193958.aspx
http://www.dotnetrangers.net/2011/10...cy-management/
Je ne sais plus si tu peux choisir entre Optimistic ou Pessimistic. A toi de te renseigner à ce sujet.

Je n'ai pas encore tout à fait compris comment ça marche mais je continue à faire des recherches dessus =)

Je finis quand même par me demander si ce ne serrait pas mieux que je crée un service côté serveur qui s'occupera de tout l'aspect accès aux données et qui gérera la concurrence entre les différents utilisateurs ... Mais le problème c'est que j'ai à ma disposition un serveur linux (je sais qu'il y a le projet Mono pour développer en C# sur linux mais je ne sais pas si c'est assez mature).
Est-ce que l'utilisation d'un service d'accès aux données est la bonne approche ?

[marcusien]

De toute façon les accès concurrentiels c'est un des plus gros casse-tête ^^

Concernant l'approche de la gestion des accès concurrentiels avec les web services pourquoi pas. C'est une des solutions que je voulais te citer mais j'avais oublié Tu peux le faire bien évidemment.

Il n'empêche qu'il faudra tout de même à un moment choisir entre optimiste et pessimiste.
Pour ma part, durant un de mes projets, on avait une architecture assez complexe mais grossièrement, je vais décrire le cas avec des points ^^

• Deux utilisateurs veulent modifier un même client
• Chacun d'eux fait une modification sur ce client
• Le premier utilisateur sauvegarde le client sans encombre
• Le deuxième souhaite sauvegarder
• Au moment de la sauvegarde, on compare le timestamp du client de l'utilisateur avec le timestamp du client qui est stocké en base. Si ils sont différents (du point de vue du deuxième utilisateur, cela signifie qu'il n'a pas fait des modifications sur la dernière version de la fiche client), alors on affiche une fenêtre de comparaison des fiches clients, un peu à la manière d'une fenêtre de merging de fichiers de code source c# ^^
  Après il avait alors le choix de faire un merge automatique (qui ne pouvait s'effectuer que si, entre les deux versions, seuls des champs différents avaient été modifiés), soit de prendre la version base de données (et donc perdre les modifs locales) ou alors d'écraser la version en base par la sienne

Après c'est vraiment des choix. Nous on avait fait ce choix car c'était un très gros client, et que c'était un ERP générique.