179 messaggi dal 13 febbraio 2004
salve a tutti

convinto di iniziare una nuova avventura di sviluppo di una nostra app con MVC, ora mi trovo d'avanti a qualche dubbio :)

il nuovo layered dell'applicazione dovrebbe essere questo:

Database -- DAL -- BL -- UI WEB

l'idea però è di prevedere anche una suddivisione delle macchine

tipo server DataBase, server classi DAL e business e server web

ovviamente tra server dati e business nessun problema, tramite tcp

invece tra BL e UI WEB pensavo di utilizzare uno strato Service tipo un WCF per una comunicazione sempre in TCP

il risultato sarebbe:

Server Database -- server DAL, BL e WCF -- server web con UI e cache

in questo modo dovremmo avere un potenziale di espansione futura molto elevata, conviene ?
Se invece dovessi utilizzare direttamente le classi business, in pratica con MVC andrebbero a sostituire i MODELS, per essere usate direttamente on i CONTROLS, utilizzando la ViewBag.

c'è qualche esempio?
grazie
11.886 messaggi dal 09 febbraio 2002
Contributi
ciao,

cristian0579 ha scritto:

in questo modo dovremmo avere un potenziale di espansione futura molto elevata, conviene?

Dipende dai costi (anche prestazionali) e dalle opportunità che questa soluzione porta con sé. Creare 3 tiers introduce una complessità architetturale che deve essere giustificata da vantaggi evidenti.

Il vantaggio di posizionare il database in un proprio server sta nel fatto che, se gli utenti dovessero aumentare, potrete aggiungere altri n webservers in load balancing e avere comunque i dati centralizzati.
Anche il servizio Database può scalare orizzontalmente e in maniera indipendente: se usi Sql Server 2012 puoi aggiungere altre macchine per creare un availability group che ti permetterà di accedere (in sola lettura) anche alle copie secondarie del database (utile per non appesantire la copia primaria quando devi fare backup, business intelligence o la parte di querying nel pattern CQRS).

Tuttavia... perché vuoi creare un tier anche per la business logic? Che vantaggio ti dà avere delle classi isolate in server a parte? La tua applicazione pagherebbe due volte la latenza di rete (seppur minima): prima per far transitare i dati dal DB alla BL e poi dalla BL alla UI.

Potresti destinare quella macchina a server di caching (es. con Appfabric per windows server), così risolvi pure il problema di dover condividere la sessione dell'utente e gli oggetti in cache tra tutte le istanze di IIS che avrai aggiunto all'infrastruttura.

Io ti scrivo queste poche righe non conoscendo nulla del tuo scenario quindi, qualsiasi scelta tu faccia, chiediti se aiuterà l'applicazione a funzionare meglio. Se la risposta è "sì", mettila in atto. Se la risposta è "ma altri hanno fatto così", scartala perché ben presto potresti trovarti a gestire sistemi troppo costosi e troppo complicati.

cristian0579 ha scritto:

Se invece dovessi utilizzare direttamente le classi business, in pratica con MVC andrebbero a sostituire i MODELS, per essere usate direttamente on i CONTROLS, utilizzando la ViewBag.

MVC non è un ostacolo all'approccio multi-tiered, puoi usarlo in combinazione con classi di business provenienti da un altro assembly.
Le Views possono essere tipizzate, quindi non devi ricorrere al ViewBag per dare il Modello in pasto alla View.

ciao
Modificato da BrightSoul il 09 ottobre 2012 23.05 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.