Structure de l'espace de noms/de la solution

Question

Je m'excuse de poser une question aussi générale, mais c'est quelque chose qui peut s'avérer difficile pour moi.Mon équipe est sur le point de se lancer dans un grand projet qui, espérons-le, rassemblera toutes les bases de code aléatoires uniques qui ont évolué au fil des ans.Étant donné que ce projet couvrira la normalisation des entités logiques au sein de l'entreprise (« Client », « Employé »), des petites tâches, des grandes tâches qui contrôlent les petites tâches et des services utilitaires, j'ai du mal à trouver la meilleure façon de structurer le espaces de noms et structure du code.

Même si je suppose que je ne vous donne pas suffisamment de détails pour continuer, avez-vous des ressources ou des conseils sur la façon d'aborder la division logique de vos domaines?Au cas où cela pourrait aider, la plupart de ces fonctionnalités seront révélées via des services Web, et nous sommes un Microsoft magasinez avec tous les derniers gadgets et gadgets.

• Je débat d'une solution massive avec des sous-projets pour faciliter les références, mais cela la rendra-t-elle trop lourde ?
• Dois-je terminer les fonctionnalités de l'application héritée ou les laisser complètement indépendantes dans l'espace de noms (en créant un OurCRMProduct.Customer classe versus un générique Customer classe, par exemple) ?
• Chaque service/projet doit-il avoir son propre BAL et DAL, ou devrait-il s'agir d'un assemblage entièrement séparé auquel tout fait référence ?

Je n'ai pas d'expérience dans l'organisation de projets d'une telle envergure, seulement des projets ponctuels, je recherche donc tous les conseils possibles.

Answer 1

Il existe un million de façons d'écorcher un chat.Cependant, le plus simple est toujours le meilleur.Quelle est la voie la plus simple pour vous ?Cela dépend de vos besoins.Mais il y a quelques règles générales que je suis.

Premièrement, réduisez autant que possible le nombre total de projets.Lorsque vous compilez vingt fois par jour, cette minute supplémentaire s'additionne.

Si votre application est conçue pour l'extensibilité, envisagez de diviser vos assemblys selon les principes de conception et de conception.mise en œuvre.Placez vos interfaces et classes de base dans une assemblée publique.Créez un assembly pour les implémentations de ces classes dans votre entreprise.

Pour les applications volumineuses, séparez la logique de votre interface utilisateur et votre logique métier.

SIMPLIFIEZ votre solution.Si cela semble trop complexe, c’est probablement le cas.Mélanger, réduire.

Answer 2

Mon conseil, après m'être lancé dans une entreprise similaire, est de ne pas vous inquiéter des espaces de noms.

Commencez simplement à développer avec quelques directives importantes, car quel que soit votre point de départ, votre projet est organique et vous volonté finissent par réorganiser les espaces de noms et les classes au fil du temps.

Ne perdez pas de temps à trop parler de votre projet.Fais-le c'est tout.

Answer 3

J'ai récemment vécu exactement la même chose au travail.Beaucoup de code ad hoc qui devait être structuré et organisé.

C'est vraiment difficile au début, car il y a tellement de choses.Je pense que le meilleur conseil que je puisse donner est simplement investir du temps là-dedans à la fin d'un vendredi après-midi, pendant quelques semaines, je choisissais simplement une application/un morceau de code, examinais ce qui s'y trouvait, réfléchissais à ce que nous pourrions rendre générique, le copiais, le mettais dans la nouvelle bibliothèque partout où je pensais ça devrait être.Une fois que j'avais migré tout le code d'une application, je travaillais ensuite à la refactorisation de l'application pour qu'elle fonctionne à partir du framework commun.Cela provoquait parfois des problèmes qui devaient être résolus, mais tant que vous êtes minutieux, cela ne devrait pas être trop grave.

Pièce par pièce, c'est la seule façon de procéder.

En termes de structure, j'ai essayé d'imiter en quelque sorte l'espace de noms MS car, pour la plupart, c'est assez logique (par ex. Les données de la compagnie , Entreprise.Web , Entreprise.Web.UI et ainsi de suite.

L’un des principaux avantages est probablement la quantité de code duplique supprimée.Oui, une petite refactorisation a été nécessaire dans les applications, mais la base de code est beaucoup plus légère et, à bien des égards, « plus intelligente ».

Une autre chose que j'ai remarquée, c'est que j'avais souvent du mal à comprendre où mettre des choses (en termes d'espacement de noms) car je n'étais pas sûr à quoi elles appartenaient.Maintenant ça vraiment me préoccupait, je le considérais comme une si mauvaise odeur.Depuis la réorganisation, tout s'intègre désormais beaucoup mieux dans l'espace.Et avec la (maintenant très petite quantité) de code spécifique à l'application, ils sont placés dans Société.Applications.ApplicationName Cela m'aide à réfléchir beaucoup plus aux objets métier, car je ne veux pas trop de choses dans cet espace de noms, je propose donc des conceptions plus flexibles.

Désolé pour le long message..C'est un peu décousu !

Answer 4

Nous nommons les assemblys dans .NET de la manière suivante Company.Project.XXXX.YYYY où XXXX est le projet et YYYYY est le sous-projet, par exemple :

• LCP.AdmCom.Common
• LCP.AdmCom.BusinessObjects
• LCP.AdmCom.Common.Dal

Nous prenons cela d'un appel de livre Lignes directrices pour la conception du cadre de Krzysztof Cwalina (Auteur), Brad Abrams (Auteur)

Answer 5

Pour les grands projets, l'approche que j'aime adopter consiste à disposer d'un espace de noms de domaine pour mes objets métier, puis à utiliser des objets de transfert de données (DTO) dans mes couches où le stockage et la récupération de l'objet métier sont nécessaires.Un DTO est un objet simple qui ne contient aucune logique métier.

Voici un lien qui explique un DTO :

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Answer 6

Les grandes solutions comportant de nombreux projets peuvent être assez lentes à compiler, mais sont plus faciles à gérer ensemble.

J'ai souvent des assemblys de tests unitaires dans la même solution que ceux qu'ils testent, car vous avez tendance à les modifier ensemble.