18 messaggi dal 17 maggio 2011
Ciao a tutti,

Ad oggi sono abituato a sviluppare applicazioni asp.net con ef codefirst.
Dovrò sviluppare un'app web sempre tramite questo approccio, ma in più ci sarà una seconda applicazione che si interfaccia con il db che usa lo stesso contesto.

Come posso trasferire un dbcontext da una app all'altra e relativi aggiornamenti nel modo migliore?

Possibili soluzioni :
la prima app usa codefirst
la seconda app usa dbfirst e per tutti gli aggiornamenti riesegue il dbfirst.

Estraggo in qualche modo dbcontext dalla prima (con relative classi) e importo nella seconda.

Altri approcci?
Cosa mi consigliate?

Ciao
Paolo
14 messaggi dal 06 marzo 2017
Ciao, ho una situazione simile, in azienda utilizziamo il controllo del codice con Bitbuket e Sourcetree, abbiamo risolto creando due rami separati, uno per ogni app (in questo caso si parla di installazione con le relative personalizzazioni, ma il concetto è lo stesso) comprendenti la UI e le API, tutti i rami però referenziano lo stesso sottomodulo che nel nostro caso è la parte DDD, quindo con il code first e il dbContext.

Questo ti permette di mantenere allineato in n progetti il dominio, ma di personalizzare o come nel tuo caso di collegarci interfacce e logiche API diverse
18 messaggi dal 17 maggio 2011
Ciao e grazie della risposta, ma mi devi perdonare proprio non ho capito.
Tu nella prima app sei partiti con code first e nella seconda come hai fatto ad avere il db context?
11.190 messaggi dal 09 febbraio 2002
Contributi
Ciao, valuta di inserire la logica in una class library che poi pubblicherai come pacchetto NuGet in un feed privato aziendale. È una buona soluzione strutturata che ti darà meno problemi rispetto ad altre soluzioni palliative.
http://www.aspitalia.com/script/1264/Creare-Feed-NuGet-Privato.aspx

ciao,
Moreno
Modificato da BrightSoul il 15 dicembre 2018 19.56 -

Enjoy learning and just keep making
18 messaggi dal 17 maggio 2011
Ciao,

Grazie della dritta mi pare perfetta come soluzione.
Come class library intendi il dbcontext e le relative entità che lo costituiscono?
Se si mi pare tutto facilmente applicabile, a parte una cosa.
Io ho implementato autenticazione microsoft e due dbcontext, uno applicationDbContext creato da microsoft e l'altro TicketingDbContex creato da te.
E' stata una scelta sbagliata quella di creare 2 dbcontext?

Ciao
Paolo
11.190 messaggi dal 09 febbraio 2002
Contributi
Ciao,


Come class library intendi il dbcontext e le relative entità che lo costituiscono?

Metti nella class library tutto ciò che vuoi condividere tra i progetti, né più né meno.


Io ho implementato autenticazione microsoft e due dbcontext, uno applicationDbContext creato da microsoft e l'altro TicketingDbContex creato da te.
E' stata una scelta sbagliata quella di creare 2 dbcontext?

L'ApplicationDbContext può essere facilmente personalizzato per includere altri tipi di entità quindi potevi usare un solo DbContext. Però dipende dallo scenario... tu perché hai scelto di crearne due? Se la motivazione è valida puoi tenerne due.

ciao,
Moreno
Modificato da BrightSoul il 18 dicembre 2018 20.06 -

Enjoy learning and just keep making
14 messaggi dal 06 marzo 2017
BrightSoul ha scritto:
Ciao, valuta di inserire la logica in una class library che poi pubblicherai come pacchetto NuGet in un feed privato aziendale. È una buona soluzione strutturata che ti darà meno problemi rispetto ad altre soluzioni palliative.


Questa è sicuramente una buona soluzione, l'unico 'problema' che ci può essere è quello comunque di avere applicazioni disallineate fino a quando non le prendi ed aggiorni il pacchetto, quasi meglio utilizzare una sorta di GAC condivisa e referenziale direttamente le dll.

Poi non ho capito, sempre se ti riferivi a quello, perché ritieni il metodo che suggerivo io un 'palliativo', visto che, per esperienza personale, confermo e ribadisco che ha notevoli vantaggi, primo fra tutti proprio quello di avere tutti i progetti sempre allineati, soprattutto fino a quando si è in fase di sviluppo!
11.190 messaggi dal 09 febbraio 2002
Contributi
Il fatto che i progetti siano automaticamente "allineati" non ti dà vantaggi particolari. E neanche aggiornare un pacchetto NuGet solo perché c'è una nuova versione, che comunque è un'operazione che richiede tipo 10 secondi.

Se in una libreria condivisa è stato pubblicato un aggiornamento, spesso è necessario che anche i progetti che dipendono da essa debbano essere aggiornati per sfruttare quella funzionalità. E' questa la vera attività che richiede un discreto quantitativo di tempo, non il fare click per aggiornare un pacchetto.

Se tu "costringi" i progetti ad aggiornarsi all'ultima versione disponibile della libreria, puoi anche introdurre degli effetti indesiderati. Guarda come fa Microsoft con ASP.NET Core: anche se nella 2.2 ci sono dei miglioramenti prestazionali, bugfixing o dei cambi di comportamento migliorativi su alcuni piccoli aspetti del framework, lasciano libero lo sviluppatore di fare opt-in a queste migliorie come e quando desidera. E' per questo che quando registri MVC devi indicare la compatibility version:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc()
        .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}


Siccome non sappiamo niente dei progetti di fractals87, secondo me l'approccio più cauto è quello di suggerirgli una soluzione che gli permetta - se vuole - di gestire i cicli di vita dei due progetti in maniera indipendente. In questo modo potrà aggiornare il pacchetto in maniera esplicita, dopo aver letto le change notes che lui stesso ha scritto, così da essere perfettamente consapevole di cosa sta facendo.

Poi, siccome questa libreria ha anche un impatto sullo schema del database, starà alla sua perizia modificarla senza introdurre delle breaking change, altrimenti si spaccano i progetti sia che le modifiche siano veicolate col submodule GIT che col pacchetto NuGet.

ciao,
Moreno
Modificato da BrightSoul il 18 dicembre 2018 23.41 -

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.