Fondamentalmente, sto cercando di capire perché strati e livelli sono così diversi e perché non si traducono facilmente l'uno con l'altro.
Capisco che i livelli potrebbero essere 3 file di classe separati per UI, BL e DAL. Mentre tiered può essere un progetto per l'interfaccia utente, che si collega a un progetto BL che si collega a un framework di entità simile a DAL e quindi a un database. Allora perché sono / non sono facilmente traducibili?
Spero che abbia senso, Grazie.
Entrambi i concetti introducono una separazione delle preoccupazioni. Ma per gli strati, la separazione delle preoccupazioni è solitamente l'obiettivo principale. I livelli sono utilizzati per la scalabilità e la distribuzione del carico / scopi di allocazione, e la separazione delle preoccupazioni è più un effetto collaterale lì.
Questo spiega anche perché i concetti non sono facilmente traducibili. In un'architettura a livelli, una funzionalità viene solitamente implementata nel livello in cui si adatta meglio semanticamente e si tenta di evitare la ridondanza tra i livelli. Nei livelli, si implementa una funzionalità in cui si hanno le risorse di calcolo per questo. La ridondanza tra i livelli è comune (ad esempio, replicare alcune logiche di business nel livello dell'interfaccia utente, ma nel livello della business logic, il controllo viene eseguito una sola volta quando i dati vengono salvati, nel livello dell'interfaccia utente il controllo viene eseguito dopo ogni input dell'utente).
Leggi altre domande sui tag architecture layers n-tier