quando introdurre un livello di servizi applicativi in un'applicazione n-tier

Sarei d'accordo con la tua valutazione iniziale. Probabilmente non ha molto senso aggiungere un hop di rete aggiuntivo nell'elaborazione del tuo sistema. La ragione per cui le persone separano i livelli fisicamente è per il riutilizzo attraverso le applicazioni. Questo è che hai più applicazioni che chiamano gli stessi servizi per eseguire una parte del loro lavoro. Come hai detto, non c'è un sacco di logica incorporata che il livello aziendale fornisce; e finora c'è solo un'applicazione che lo usa.

È positivo che tu abbia separato i livelli logicamente, ma una separazione fisica in questo momento potrebbe essere eccessiva.

Aggiornamento per risolvere i problemi di scalabilità

Continuo a sostenere che mantenere la BLL sullo stesso livello fisico del livello di presentazione è l'approccio migliore per ora. È possibile ridimensionare aggiungendo più nodi di presentazione / bll (già risolti se si utilizza un'implementazione di un client grasso, abbastanza semplice da eseguire con un'applicazione Web). Inoltre, se si scopre che il database sta diventando il collo di bottiglia, la maggior parte dei database supporta clustering / sharding e altri trucchetti per ridimensionarli. Solo dopo aver esaminato entrambi questi percorsi (e ovviamente aggiungendo nella cache distribuita), dovrei considerare l'aggiunta di un altro livello fisico.

Tuttavia, prima di poter andare lì, inizierei a creare un Business Layer più "sostanzioso" di una semplice facciata per il Data Access Layer. Il primo passo è considerare l'utilizzo di un potente O / RM che esegue il mapping dei dati per te. Quindi considera la possibilità di rendere più intelligenti i tuoi oggetti di business. Ci sono risme di articoli scritti su Domain Driven Design (il libro è un ottimo punto di partenza). Passare attraverso i passaggi della modellazione di domini, definire contesti limitati e trovare radici aggregate ti aiuterà a produrre un'architettura che abbia cuciture naturali. Ciò ti aiuterà a suddividere la tua applicazione in servizi autonomi che possono essere scalati autonomamente secondo necessità.

Suppongo che tu stia usando il termine "tier" per indicare un server fisico. Se non hai bisogno di distribuire il tuo livello aziendale e di presentazione, lo eviterei sicuramente. L'invio di oggetti sul filo è costoso e soggetto a problemi che, se possono essere evitati, dovrebbero. Ma dovresti progettare la tua architettura in un modo che faciliti l'aggiunta di più livelli man mano che il sistema evolve e le considerazioni sulla progettazione giustificano la distribuzione. Di solito sviluppo un'applicazione livello di servizio come libreria / assembly di classi che avrebbe la stessa interfaccia del servizio WCF. Questo è ciò con cui il livello di presentazione si interfaccia o con qualsiasi altro sistema esterno. Se i livelli aziendali e di presentazione non devono essere distribuiti, il livello di presentazione fa riferimento direttamente alla libreria di classi. Se devono essere distribuiti, il servizio WCF è solo un involucro sottile attorno alla libreria di classi del livello di servizio che offre la possibilità di accedere al servizio in remoto.

Tenere d'occhio il futuro di solito è una buona cosa, ma l'introduzione di un livello di servizio, o qualsiasi cosa in realtà, quando uno non è necessario potrebbe essere solo una perdita di tempo e rallentare il sistema.

La suddivisione corretta del sistema in livelli logici è deinitivamente una buona cosa e ti consentirà di estendere il tuo sistema in un secondo momento. Ridurre l'accoppiamento renderà più semplice farlo in futuro.

Come è successo, ho lavorato su un grande sistema un paio di anni fa, che era un sito web - > livello di servizio - > tutto il resto.

Il livello di servizio è stato introdotto perché tutti i senior architects / manager si sono innamorati di SOA, quindi il nostro sistema doveva essere orientato al servizio. "altri sistemi useranno le nostre funzionalità di livello intermedio dei siti Web" è stato il grido.

Questa decisione è costata al progetto un ritardo di un anno.