Quelle est la meilleure façon de structurer un projet ?[fermé]

Question

Je me demandais comment structurer mes projets.

Nous avons certains projets qui sont (ré)utilisés dans d'autres projets.

Je veux dire, notre projet de données et notre projet de modèle sont utilisés dans un à plusieurs autres projets.

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, cela devrait ressembler à quelque chose comme :

1. DAL, DataAccessLayer, Données...
2. Modèle, BusinessObject, BOL...
3. Interface utilisateur, Vue, ...

D'autres idées ?

Dans chaque entreprise dans laquelle je travaille, il y a une manière différente de s'organiser, y en a-t-il une meilleure qu'une autre ?Lequel utilisez-vous et lequel préférez-vous et pourquoi ?

Merci!

Answer 1

Pour la couche de données, j'utilise généralement :

Société.NomProjet.Données (c'est à dire.AdventureWorks.OrderManager.Data)

Pour la couche métier, je préfère quelque chose comme "ObjectModel" (j'ai utilisé "Business" ou "BusinessLogic" mais c'est le domaine où les données sont rassemblées en objets/classes, alors pourquoi ne pas le nommer ainsi ?).

Société.NomProjet.ObjectModel (c'est à dire.AdventureWorks.OrderManager.ObjectModel)

Pour l'interface utilisateur, j'aime soit le vieux "UI" soit la "Présentation"...

Société.NomduProjet.Présentation (c'est à dire.AdventureWorks.OrderManager.Présentation)

Answer 2

Cest à peu près ce que je fais, à l'exception Ive a obtenu deux projets de bibliothèque où j'essaie de mettre tout mon code réutilisable. Ensuite, mon modèle et DAL sont assis sur le dessus de ces librarys, tout en ajoutant des détails de projet pour les

Answer 3

La plupart du temps j'utilise l'architecture en couches comme recommandé dans Microsoft modèles et pratiques Architecture d'application pour .NET: Applications et services Conception . Document décrit les technologies d'architecture et de .NET pour la mettre en œuvre.

Answer 4

L'architecture logicielle dépend du type de logiciel pour construire. Si vous voulez faire d'autres principes de programmation du noyau appliquent par rapport à faire le développement d'applications. Pourtant, un autre des principes applicables lorsque votre vont faire la simulation physique, logiciel prévisions météorologiques, le logiciel IDE ou compilateurs.

Je suppose que vous voulez faire developement application. Eh bien, alors vous voudrez probablement plus de concevoir votre logiciel dans le domaine que vous allez réfléchir. 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 5

Je travaille actuellement sur l'application web front-end qui a une architecture à 3 niveaux:

• Niveau client (le navigateur)
• Niveau application (Java EE du serveur d'applications, où l'application habitera)
• 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 de présentation: génère l'interface utilisateur qui sera utilisé dans le niveau du client
• couche d'application: l'équivalent de cas d'utilisation, contient la logique d'application
• couche de 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, la structure du projet, et le résultat final dépendra du type d'application. Vous pouvez en lire plus dans ma réponse cette question sur la division et de la stratégie de nommage pour les packages.

Vous pouvez ajouter / swap / enlever des couches comme bon vous semble. Dans une architecture SOA par exemple, vous pouvez superposer une couche de Webservice sur le dessus de la couche de la couche d'application ou service, de sorte que l'ESB (Enterprise Service Bus) peut se connecter à votre application ou de services. Si tout cela est impossible ou semble très difficile, vous ne disposez pas d'une architecture optimale et le design.

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

• testabilité
• réutilisabilité
• maintenabilité

Vous pouvez y parvenir en concevant pour un couplage faible et une forte cohésion. Le choix d'une architecture en couches par des modules regroupant par le niveau de fonctionnalité / abstraction est un bon début. Au sein de chaque couche autre regroupement par fonctionnalité aide aussi bien. Laissant seulement chaque couche plus précise dépendra des interfaces d'une couche plus général réduit aussi le couplage.