none
Comment organiser une application n-tier avec plusieurs projets sous la même compagnie? RRS feed

  • Discussion générale

  • Bonjour à tous,

    Je veux solliciter votre temps car j’ai besoin de conseils sur la façon dont je dois établir l’architecture de mon application. Je recherche idéalement les meilleurs pratiques que les professionnels ont probablement déjà établis quelque part.

    Tout d’abord, il est très important que vous sachiez que mon entreprise aura plusieurs projets. La plupart des projets seront codés en MVC5 et C# selon une architecture 3-tiers. Vous devinerez donc que mon objectif est de grouper chaque application sous le nom de ma compagnie.

    Alors commençons immédiatement!! J'ai lu pendant près de 4 heures plusieurs articles MSDN et des blogs de toutes sortes pour en arriver à la conclusion que l'architecture qui pourrait respecter les bonnes pratiques ressemblerait à ceci (j'ajouterai les références au bas ma discussion) :

    MaCompanie (Solution)

    • MaCompanie.Common
    • Folder Projet 1
      • Folder Integration
        • MaCompanie.Projet1.Controllers.Test.Integration
      • Folder Performance
        • MaCompanie.Projet1.Service.Test.Performance
      • Folder UI
        • MaCompanie.Projet1.Website.Test.UI
      • Folder Unit
        • MaCompanie.Projet1.Controllers.Test.Unit
      • MaCompanie.Projet1.Website (Razor, Controllers…)
      • MaCompanie.Projet1.Domain
        • MaCompanie.Projet1.Domain.Models
        • MaCompanie.Projet1.Domain.ViewModels
        • MaCompanie.Projet1.Domain.Enumerations
        • MaCompanie.Projet1.Domain.Expressions (predicate expression)
        • MaCompanie.Projet1.Domain.Attributes (validator)
      • MaCompanie.Projet1.DataAccess
        • MaCompanie.Projet1.DataAccess.Repositories
      • MaCompanie.Projet1.Domain.Service
        • MaCompanie.Projet1.Domain.Service.Utilities
    • Folder Projet 2
      • Folder Integration
        • MaCompanie.Projet2.Controllers.Test.Integration
      • Folder Performance
        • MaCompanie.Projet2.Service.Test.Performance
      • Folder UI
        • MaCompanie.Projet2.Website.Test.UI
      • Folder Unit
        • MaCompanie.Projet2.Controllers.Test.Unit
      • MaCompanie.Projet2.Website (Razor, Controllers…)
      • MaCompanie.Projet2.Domain
        • MaCompanie.Projet2.Domain.Models
        • MaCompanie.Projet2.Domain.ViewModels
        • MaCompanie.Projet2.Domain.Enumerations
        • MaCompanie.Projet2.Domain.Expressions (predicate expression)
        • MaCompanie.Projet2.Domain.Attributes (validator)
      • MaCompanie.Projet2.DataAccess
        • MaCompanie.Projet2.DataAccess.Repositories
      • MaCompanie.Projet2.Domain.Service
        • MaCompanie.Projet2.Domain.Service.Utilities

    Cependant, j'ai encore un doute et j'aimerais avoir votre avis afin de peaufiner au maximum l'architecture de mes applications, selon les meilleurs pratiques bien-entendu. Quels sont vos commentaires ou suggestions? 

    Biens à vous,

    David Létourneau

    Références :

    1. http://programmers.stackexchange.com/questions/40394/how-do-you-organize-your-projects
    2. http://msdn.microsoft.com/en-us/magazine/jj190803.aspx
    3. http://www.dennisdoomen.net/2012/07/if-you-write-article-about-tdd-make.html
    4. http://radicaldevelopment.net/practices-visual-studio-net-project-naming-standards/
    5. http://pnp.azurewebsites.net/en-us/
    dimanche 2 novembre 2014 05:15

Toutes les réponses

  • Bonjour,

    De manière générale, j'ai tendance à limiter le nombre de projets chez mes clients au début du développement pour les raisons suivantes :

    • Problèmes de performances de compilation / utilisation de Visual Studio
    • Le client envisage un projet sur 10 ans qui va révolutionner le monde, mais la réalité fait que le projet est arrêté au bout de 1 an ou 2 car il y a d'autres projets surlequel travailler...
    • Le client souhaite une application multi IHM, multi base,... multi n'importe quoi... En revanche les développeurs ne sont pas multi n'importe quoi... Donc passer de SQL Server à Oracle nécessite à changer le DBA, passer d'une interface Web à WPF ou inversement nécessite des compétences différentes,...

    Il faut aussi comprendre que les projets C# ne forment pas l'architecture de votre application ! Ce sont les liens entre les classes ! Les projets C# sont justes des conteneurs physiques (assemblys) qui contiennent vos classes...

    J'ai déjà fait des petits projets n-tiers qui sont dans une seul et même assembly (car l'utilisation de 50 classes). Et mon découpage à l'intérieur était tout à fait correcte !

    Dans votre cas j'aurai tendance à faire un seul projet pour la partie "Domain" (donc fusionner vos Models, ViewModels, Enumerations, Expressions,...) dans un seul projet.

    Par contre le plus souvent je vais en sorte que j'ai un projet de test par projet. Je ne met pas tous les tests de tous les projets... Cela permet de récupérer plus facilement des projets C# (avec les tests)... 

    Cordialement


    Gilles TOURREAU - MVP C#
    Architecte logiciel/Consultant/Formateur Freelance - P.O.S Informatique
    Blog : http://gilles.tourreau.fr - Suivez-moi sur Twitter
    - MCPD : Enterprise Developper / Windows Developper 3.5 / ASP .NET 3.5/4.0
    - MCSA : SQL Server 2012
    - MCITP : SQL Server 2008 Developper
    - MCTS : ADO .NET 3.5 / SQL Server 2008 Developper / Windows Forms 3.5 / ASP .NET 3.5/4.0 / TFS 2010 / Windows Azure

    dimanche 2 novembre 2014 17:18
    Modérateur
  • Bonjour,

    Tout à fait d'accord avec Gilles sur la limitation des projets. Et pareil pour ceux qui prônent l'IoC en disant que demain, si l'on passe de SQL Server à Oracle, ce sera facile. Non, par nature, ce sera un cauchemar de changer de base et la problématique du programme n'est qu'un petit aspect ;-)

    J'ajouterai :

    1/ Par définition, un "folder" doit contenir au moins 2 projets sinon cela n'a pas de sens.

    2/ Je vois souvent des solutions avec plein de projets pour faire "bien organisé". Et quand on entre dans les projets, on voit que c'est le b... dans les namespaces. Il est beaucoup plus important de bien organiser ses namespaces que ses projets.

    3/ Votre développement est un projet fonctionnel, pas technique. Si vous parlez avec le chef de projet fonctionnel et que vous lui parlez de predicate, il vous regardera avec de grands yeux. En revanche, si l'on parle de type de facture, il semble naturel d'aller le chercher dans le namespace MaCompagnie.Domain.Comptabilite plutôt que dans MaCompagnie.Domain.Enumeration.

    4/ La décomposition "minimale" (et obligatoire de mon point de vue), c'est projet UI + projet Business (avec les modèles, services et DAL).

    Enfin, il y a quelques points qui m'interpellent dans votre solution : vous prévoyez des predicate. Pourquoi ? Cela ne peut pas se faire "simplement" ?

    Je ne suis pas persuadé qu'il faille mettre tout vos projets dans une seule solution : je pense ici surtout aux tests de perfs.

    Mais en une phrase : soyez simple et bien organisé et tout ira bien.


    Richard Clark
    Consultant - Formateur .NET
    http://www.c2i.fr
    Depuis 1996: le 1er site .NET francophone

    jeudi 6 novembre 2014 10:30