Devo utilizzare diversi progetti per costruire diversi livelli in un modello a 3 strati?

Creerei sicuramente 3 progetti separati per ogni livello che speri di creare. Usando progetti separati rende la tua soluzione molto più individuabile e manutenibile.

Per saperne un po 'di più su quando suddividere i progetti, vedi questo risposta

Nella soluzione che crei puoi creare cartelle delle soluzioni che ben separano i progetti in aree più gestibili.

Puoi avere cartelle di soluzioni che prendono il nome da ogni livello che vuoi creare.

• Entità aziendale
• Business Logic
• Livello di logica dei dati

La pratica di mettere ogni livello della tua applicazione in un progetto separato è comune nel mondo .net, ed è vista da alcuni come una "migliore pratica", ma nella mia esperienza, in realtà causa più problemi di risolve. In particolare:

• Rende più difficile l'aggiornamento dei riferimenti di terze parti, dato che si può finire fin troppo facilmente con riferimenti a due diverse versioni dello stesso assembly. NuGet allevia il problema in una certa misura, ma nella mia esperienza non lo elimina del tutto.
• Rallenta i tempi di compilazione.
• Causa problemi con le dipendenze circolari: prima o poi ci sarà un insieme di classi che dovrai aggiungere al tuo codice, solo per scoprire che non sei sicuro se appartengano al tuo livello aziendale, al tuo DAL, o da qualche altra parte. Le probabilità sono alte che tu possa sbagliare per qualche motivo la prima volta e spostarle in un assembly separato, aggravando il problema.
• Ti costringe a saltare attraverso parti ampiamente separate della tua soluzione per seguire il flusso del tuo codice.

Mettere i diversi livelli in assembly separati è anche una violazione del Common Closure Principle , che dice che le classi che cambiano insieme dovrebbero essere confezionati insieme. Gli assembly - e quindi i progetti di Visual Studio - sono un'unità di implementazione, non un'unità di organizzazione. Se vuoi organizzare il tuo codice in base a diversi livelli, questo è il namespace sono per.

Generalmente è una buona idea separare gli aspetti del tuo prodotto in componenti separati ed estrarli a moduli indipendenti il più possibile (o progetti, se vuoi).

Tuttavia, non è necessariamente così facile da fare in tutte le lingue, dal momento che il livello di strumenti a disposizione può variare notevolmente e una soluzione a bassa tecnologia potrebbe essere un buon compromesso tra un design decente e tirando fuori il tuo hait per ore a fare la tua build è conforme a un'architettura ideale.

Considerando che hai aggiunto il tag C #, che ho lasciato come penso che aiuti ad assumere gli strumenti che hai, anche se non è rilevante per la lingua, avrei davvero raccomandato di separare il tuo progetto in 3 progetti come parte di una singola soluzione.