Quelle est la meilleure façon de structurer un projet?

Question

Je me demandais comment je devrais structurer mes projets.

Nous avons des projets qui sont (re) utilisés dans d'autres projets. Je veux dire, notre projet de données et notre projet de modèle sont utilisés dans d'autres projets un-à-plusieurs.

Ce que je dois vraiment savoir, c'est comment structurer ce type de projet, quelle est la meilleure façon de le nommer?

Dans une application standard 3 niveaux, est quelque chose comme devrait:

1. DAL, DataAccessLayer, données ...
2. Modèle, BusinessObject, BOL ...
3. UI, vue, ...

Autres idées?

Dans chaque entreprise où je travaille, il y a différentes manières de l'organiser, y en a-t-il une meilleure qu'une autre? Lequel utilisez-vous et lequel préférez-vous et pourquoi?

Thx!

Answer 1

Pour la couche de données, je l'habitude d'utiliser:

Company.ProjectName.Data (c.-à-AdventureWorks.OrderManager.Data)

Pour la couche d'affaires, je préfère quelque chose comme "ObjectModel" (je l'ai utilisé "Business" ou "BusinessLogic" mais c'est la zone où les données se retrouvent dans les objets/classes alors pourquoi ne pas le nommer ainsi?).

Company.ProjectName.ObjectModel (c.-à-AdventureWorks.OrderManager.ObjectModel)

Pour l'interface utilisateur, j'aime soit bon vieux "interface utilisateur" ou "Présentation" ...

Company.ProjectName. Présentation (ie AdventureWorks.OrderManager.Présentation)

Answer 2

C'est à peu près ce que je fais, sauf que j'ai eu quelques projets de bibliothèque où j'essaie de mettre tout mon code réutilisable. Ensuite, mon modèle et DAL sont placés au-dessus de ces bibliothèques, en y ajoutant simplement les détails du projet.

Answer 3

L'architecture logicielle dépend du type de logiciel à construire. Si vous voulez faire la programmation du noyau, d'autres principes s'appliquent par rapport au développement d'applications. Encore un autre principe s'applique lorsque vous allez faire de la simulation physique, des logiciels de prévision météo, des IDE logiciels ou des compilateurs. Je suppose que vous voulez faire un développement d'application. Bien, alors vous voudrez probablement concevoir votre logiciel autour du domaine que vous allez refléter. Mais même alors, il y a beaucoup d'options.

Pour plus de perspicacité dans ce grand sujet, je vous suggère fortement de lire Domain Driven Design de Eric Evans et Applying Domain-Driven Design and Patterns de Jimmmy Nilsson.

Answer 4

Je travaille actuellement sur l'application Web frontal qui a une architecture à 3 niveaux:

• Niveau client (le navigateur)
• niveau d'application (serveur d'applications Java EE, où le application en direct)
• niveau backend (mainframe et les applications existantes, diverses bases de données)

Il a une architecture en couches et les couches dans la couche d'application sont:

• couche Présentation: génère l'interface utilisateur qui sera utilisé dans le niveau client
• couche d'application: l'équivalent de cas d'utilisation, contient une logique d'application
• couche service: cartes logiques de domaine et des données de niveau Backend sur un modèle Java
• couche d'intégration: communique avec le niveau backend et contient des passerelles pour JMS, email, ... et OTI et d'autres choses

Ceci est juste un exemple structure du projet, et le résultat final dépendra du type d'application. Vous pouvez en lire plus dans my answer à this question sur la stratégie de division et de dénomination des paquets.

Vous pouvez ajouter/échanger/supprimer des calques comme bon vous semble. Dans une architecture SOA, par exemple, vous pouvez superposer une couche Webservice au-dessus de la couche Application ou de la couche Service, afin que l'ESB (Enterprise Service Bus) puisse se connecter à votre application ou à vos services. Si cela est impossible ou semble très difficile, vous n'avez pas une architecture et un design optimaux.

Lorsque vous pensez à la structure de votre projet et pour permettre des scénarios comme celui ci-dessus, certaines propriétés importantes de vos modules et composants que vous voulez sont:

• testabilité
• réutilisabilité
• maintenabilité

Vous pouvez réaliser ceci en concevant pour le couplage bas et la cohésion élevée. Choisir une architecture en couches en regroupant les modules par niveau de fonctionnalité/abstraction est un bon début. Au sein de chaque groupe de couches, la fonctionnalité contribue également. Laisser chaque couche plus spécifique dépendre uniquement des interfaces d'une couche plus générale réduit également le couplage.

Answer 5

Généralement j'utilise l'architecture en couches comme recommandé dans Microsoft Patterns & Pratiques Application Architecture for .NET: Designing Applications and Services. Document décrit l'architecture et les technologies .NET pour l'implémenter.