Qual è il modo migliore per strutturare un progetto?[chiuso]

Question

Mi chiedevo come dovrei strutturati i miei progetti.

Abbiamo alcuni progetti che sono (ri)utilizzare in altri progetti.

Voglio dire, i nostri dati di progetto e il modello di progetto sono in uso in uno-a-molti altri progetti.

Quello che mi è veramente cosa da sapere è come struttura di questo tipo di progetto, qual è il modo migliore per nome ?

In standard 3-livello di applicazione, si dovrebbe come qualcosa di simile :

1. DAL, DataAccessLayer, Dati ...
2. Modello, BusinessObject, BOL ...
3. UI, Vista, ...

Altre idee ?

In ogni azienda per cui lavoro, hanno avuto modo diverso di organizzare, c'è uno migliore di un altro ?Quale utilizzare e quale preferisci e perché ?

Thx!

Answer 1

Per lo strato di dati, io di solito uso:

Società.ProjectName.Dati (cioèAdventureWorks.Il nostro dental manager.Dati)

Per il livello aziendale preferisco qualcosa come "ObjectModel" (ho usato il "Business" o "BusinessLogic" ma questa è l'area in cui i dati si fondono in oggetti/classi, quindi perché non un nome così?).

Società.ProjectName.ObjectModel (cioèAdventureWorks.Il nostro dental manager.ObjectModel)

Per l'interfaccia utente, mi piace sia la pianura vecchio "UI" o "Presentazione"...

Società.ProjectName.Presentazione (cioèAdventureWorks.Il nostro dental manager.Presentazione)

Answer 2

Questo è più o meno quello che faccio, tranne che Ive ha ottenuto un paio di progetti di biblioteca dove cerco di mettere tutto il mio codice riutilizzabile. Poi il mio modello e DAL siedono in cima a questi librarys, solo l'aggiunta di specifiche di progetto a loro

Answer 3

Per lo più io uso architettura a strati come raccomandato in Microsoft Patterns & Practices Application Architecture for NET: Applicazioni e Servizi Progettazione . Documento descrive le tecnologie dell'architettura e NET per attuarlo.

Answer 4

L'architettura software dipende dal tipo di software per costruire. Se si vuole fare di programmazione del kernel altri principi si applicano rispetto a fare lo sviluppo di applicazioni. Ancora un altro principi si applicano quando la vostra intenzione di fare la simulazione fisica, il software tempo-meteo, il software IDE o compilatori.

Presumo che vuoi fare sviluppo delle applicazioni. Bene, allora si avrà probabilmente vuole progettare il software in circolazione il dominio che si sta per riflettere. Ma anche allora ci sono un sacco di opzioni.

Per un quadro più chiaro in questo grande argomento, vi consiglio caldamente di leggere Domain Driven Design da Eric Evans e Applying Domain-Driven Design and Patterns da Jimmmy Nilsson.

Answer 5

Al momento sto lavorando su applicazioni web front-end che ha un'architettura a 3 livelli:

• Livello client (il browser)
• livello applicazione (application server Java EE, in cui l'applicazione vivrà)
• Backend Tier (mainframe e legacy applicazioni, diverse banche dati)

Ha un'architettura a strati, e gli strati nel livello di applicazione sono:

• livello di presentazione: genera l'interfaccia utente che verrà utilizzato nel livello client
• livello di applicazione: l'equivalente di casi d'uso, contiene la logica dell'applicazione
• livello di servizio: mappe logica di dominio e i dati da backend livello su un modello di Java
strato di
• Integrazione: comunica con il livello di backend e contiene gateway per JMS, e-mail, ... e DAO e altre cose

Questo è solo una struttura esempio progetto, e il risultato finale dipenderà dal tipo di applicazione. Si può leggere di più in la mia risposta per questa domanda sulla divisione e la strategia di denominazione per i pacchetti.

È possibile aggiungere / swap / rimuovere gli strati, come si vede in forma. In una SOA per esempio, è possibile sovrapporre uno strato Webservice sulla parte superiore dello strato di strato di applicazione o il servizio, in modo che l'ESB (Enterprise Service Bus) in grado di connettersi alla vostra applicazione o di servizi. Se uno qualsiasi di questo è impossibile o sembra molto difficile, non si dispone di un'architettura e il design ottimale.

Quando si pensa alla struttura del progetto e per consentire scenari come quello di cui sopra, alcune importanti proprietà dei vostri moduli e componenti che si desidera sono:

• Testabilità
• Riusabilità
• Maintainability

È possibile raggiungere questo obiettivo attraverso la progettazione a basso accoppiamento e alta coesione. La scelta di un'architettura a livelli raggruppando moduli dal livello di funzionalità / astrazione è un buon inizio. All'interno di ogni strato raggruppamento ulteriormente funzionalità contribuisce pure. Lasciando ogni strato più preciso dipendere solo interfacce di un livello più generale riduce accoppiamento troppo.