Qual è il modo corretto per progettare più applicazioni ASP.NET MVC che gestiscono dati simili?

3

Attualmente sto lavorando per sostituire un gruppo di applicazioni legacy. Il primo si sta avvicinando al rilascio, il che significa che inizierò il secondo.

Ogni applicazione riguarda una parte specifica di un processo di vendita. Acquisizione iniziale da parte dei clienti (con dati di clienti potenzialmente molto piccoli, molti dei quali facoltativamente volutamente), fino all'effettivo processo di quotazione / vendita, e poi a un'applicazione che mostra come riportare i clienti all'inizio del processo di acquisizione delle vendite .

Ora ho sviluppato applicazioni per molti anni, ho usato tecniche diverse, tutte con i loro pro / contro, senza conoscere davvero il modo preferito.

  1. Un grande database, riutilizzato da tutte le applicazioni per condividere i dati dei clienti ecc. Ciò può rendere molto lavoro da mantenere, avendo un sacco di sviluppatori che lavorano tutti sullo stesso schema e servizi, avendo una dipendenza dalla maggior parte probabilmente dovranno rilasciare tutte le applicazioni contemporaneamente dopo le modifiche
  2. La suddivisione del database per area (cliente, vendite, gerarchia aziendale, ecc.) fornisce una suddivisione logica, ma sono ancora tutti utilizzati da tutte le applicazioni, tuttavia i join per i dati tra database possono causare problemi a meno che non si effettuino join tra database diversi / link server ecc.
  3. Ogni singola applicazione ha il proprio set di database. Ciò rende lo sviluppo di ciascuna applicazione molto più rapido e semplice. Eppure dà anche un sacco di duplicazioni nei dati copiandoli su ogni applicazione. Quindi eventuali modifiche ai dati devono essere sincronizzate in qualche modo con altri database. Per alcune aree potresti aprire un'API web per ottenere alcuni dati tra di loro, ma molto spesso potresti dover leggere da un database per usare quelle informazioni per ottenere più informazioni da un altro ecc piuttosto che fare una semplice veloce si unisce.

Qualcuno può dare alcune informazioni nel modo corretto? Sì, le cose possono essere soggettive, ma sono sicuro che uno di questi modi sarebbe più consigliato dell'altro.

    
posta eyeballpaul 09.03.2015 - 22:21
fonte

3 risposte

2

I microservizi sono la tendenza attuale e corrispondono approssimativamente alla terza scelta. Puoi dedicare molto tempo a risucchiare la letteratura sui microservizi, ma sì, sicuramente dovrai fare i conti con un certo grado di duplicazione dei dati e possibili problemi di prestazioni quando componi più microservizi in un prodotto utilizzabile.

In definitiva non esiste una risposta giusta o sbagliata. Prendi la letteratura sui microservizi con un granello di sale. Non sono sempre una buona scelta.

    
risposta data 09.03.2015 - 22:31
fonte
2

Crea un livello dati corrispondente al tuo DB in un assembly condiviso. È possibile fare riferimento a ciascuno dei livelli aziendali (il livello dati potrebbe essere tutte le interfacce per mantenere separata l'implementazione). Quindi crea ciascuno dei tuoi casi d'uso nei livelli aziendali pertinenti. Probabilmente avrai un quarto assembly aziendale che contiene oggetti che implementano casi d'uso condiviso.

    
risposta data 10.03.2015 - 00:51
fonte
2

Gli schemi sono una via di mezzo tra database diversi e gli svantaggi di avere database diversi. Puoi avere il tuo cliente e i tuoi schemi di vendita, mantenendoli del tutto indipende o misti secondo le necessità.

Questo ti dà (2) senza i grattacapi principali con database diversi: i join sono nel database, l'installazione è semplice (nessun server collegato), i dati sono tutti tenuti insieme (a seconda delle dimensioni e dell'utilizzo questo può essere positivo o negativo ).

    
risposta data 06.09.2015 - 07:20
fonte

Leggi altre domande sui tag