Struttura dello spazio dei nomi/della soluzione

Question

Mi scuso per aver posto una domanda così generalizzata, ma è qualcosa che può rivelarsi impegnativo per me.Il mio team sta per imbarcarsi in un grande progetto che, si spera, riunirà tutti i codici base casuali che si sono evoluti nel corso degli anni.Dato che questo progetto riguarderà la standardizzazione delle entità logiche in tutta l'azienda ("Cliente", "Dipendente"), compiti piccoli, compiti grandi che controllano i compiti piccoli e servizi di utilità, faccio fatica a trovare il modo migliore per strutturare il spazi dei nomi e struttura del codice.

Anche se immagino di non darti abbastanza dettagli per andare avanti, hai qualche risorsa o consiglio su come affrontare la suddivisione logica dei tuoi domini?Nel caso possa essere d'aiuto, la maggior parte di queste funzionalità verranno rivelate tramite servizi web e noi siamo un Microsoft acquista con tutti gli ultimi aggeggi e gadget.

• Sto discutendo una soluzione massiccia con sottoprogetti per rendere più facili i riferimenti, ma questo la renderà troppo ingombrante?
• Dovrei concludere la funzionalità dell'applicazione legacy o lasciarla completamente agnostica nello spazio dei nomi (creando un file OurCRMProduct.Customer classe rispetto a un generico Customer classe, per esempio)?
• Ogni servizio/progetto dovrebbe avere il proprio BAL E DAL, o dovrebbe trattarsi di un assieme completamente separato a cui tutto fa riferimento?

Non ho esperienza nell'organizzazione di progetti di così vasta portata, solo una tantum, quindi sto cercando tutta la guida che posso ottenere.

Answer 1

Ci sono milioni di modi per scuoiare un gatto.Tuttavia, il più semplice è sempre il migliore.Qual è la strada più semplice per te?Dipende dalle tue esigenze.Ma ci sono alcune regole generali che seguo.

Innanzitutto, ridurre il più possibile il numero complessivo di progetti.Quando compili venti volte al giorno, quel minuto in più si somma.

Se la tua app è progettata per l'estensibilità, valuta la possibilità di suddividere gli assiemi in base alla progettazione e all'ottimizzazione.implementazione.Posiziona le tue interfacce e classi base in un assembly pubblico.Creare un assembly per le implementazioni di queste classi da parte dell'azienda.

Per le applicazioni di grandi dimensioni, mantieni separate la logica dell'interfaccia utente e la logica aziendale.

SEMPLIFICA la tua soluzione.Se sembra troppo complesso, probabilmente lo è.Combina, riduci.

Answer 2

Il mio consiglio, avendo intrapreso un'impresa simile, è di non arrovellarsi sugli spazi dei nomi..

Inizia a sviluppare con alcune importanti linee guida vaghe, perché comunque inizi, il tuo progetto è organico, e tu Volere finiscono per riorganizzare gli spazi dei nomi e le classi nel tempo.

Non perdere tempo a parlare troppo del tuo progetto.Fallo e basta.

Answer 3

Recentemente ho sperimentato esattamente la stessa cosa al lavoro.Un sacco di codice ad hoc che doveva essere strutturato e organizzato.

All'inizio è davvero difficile, dato che c'è così tanto.Penso che il miglior consiglio che potrei dare è semplicemente investire tempo in esso nel relax di un venerdì pomeriggio, per un paio di settimane sceglievo semplicemente un'app/un pezzo di codice, esaminavo cosa c'era, pensavo a cosa potevamo rendere generico, lo copiavo, lo mettevo nella nuova libreria ovunque pensassi dovrebbe essere.Una volta migrato tutto il codice all'interno di un'applicazione, lavorerei sul refactoring dell'applicazione per funzionare dal framework comune.Ciò a volte causava problemi che dovevano essere risolti, ma a patto che tu sia approfondito, non dovrebbe essere un grosso problema.

Pezzo per pezzo, questo è l'unico modo per farlo.

In termini di struttura, ho provato a imitare lo spazio dei nomi MS poiché per la maggior parte è abbastanza logico (ad es. Dati aziendali , Azienda.Web , Azienda.Web.UI e così via.

Uno dei maggiori vantaggi è probabilmente la quantità di codice duplicato rimosso.Sì, nelle app è stato richiesto un piccolo refactoring, ma il codice base è molto più snello e per molti versi "più intelligente".

Un'altra cosa che ho notato è che spesso avevo problemi a cercare di capire Dove per mettere cose (in termini di spazio dei nomi) poiché non ero sicuro a cosa appartenessero.Ora questo Veramente mi preoccupava, lo vedevo come un cattivo odore.Dopo la riorganizzazione, tutto ora rientra nello spazio in modo molto più gradevole.E con la quantità (ora molto piccola) di codice specifico dell'applicazione, vengono inseriti Company.Applications.ApplicationName Questo mi aiuta a pensare molto di più agli oggetti business poiché non voglio troppo all'interno di questo spazio dei nomi, quindi creo progetti più flessibili.

Ci scusiamo per il lungo post..È un po' sconclusionato!

Answer 4

Chiamiamo gli assembly in .NET nel modo seguente Company.Project.XXXX.YYYY dove XXXX è Project e YYYYY è sottoprogetto, ad esempio:

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

Lo prendiamo da una book call Linee guida per la progettazione della struttura di Krzysztof Cwalina (Autore), Brad Abrams (Autore)

Answer 5

Per progetti di grandi dimensioni, l'approccio che preferisco adottare è quello di avere uno spazio dei nomi di dominio per i miei oggetti business e quindi utilizzare Data Transfer Objects (DTO) nei miei livelli in cui è necessario l'archiviazione e il recupero dell'oggetto business.Un DTO è un oggetto semplice che non contiene alcuna logica aziendale.

Ecco un collegamento che spiega un DTO:

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

Answer 6

Le soluzioni di grandi dimensioni con molti progetti possono essere piuttosto lente da compilare, ma sono più facili da gestire insieme.

Ho spesso gruppi di test unitari nella stessa soluzione di quelli che stanno testando, poiché tendi ad apportare modifiche insieme.