I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio
E' un commento allo script #1333
fractals87
fractals87
il 12 luglio 2019 alle 14:18
80 messaggi dal 17 maggio 2011
Ciao,

Guida molto ben fatta, ho solo una domanda che non mi torna.
Nel .NET (sempre seguendo la vs. vecchia guida) avevo la possibilità di settare il Thread.CurrentThread.CurrentCulture e poi in ogni dove della mia app, in particolare nel metodo seed del contextinitializer...


public class ApplicationDbContextInitializer : CreateDatabaseIfNotExists<ApplicationDbContext>
{
protected override void Seed(ApplicationDbContext db)
{
                //Verifico la lingua di installazione e setto 
                //Get the {language} parameter in the RouteData
                string lang = System.Configuration.ConfigurationManager.AppSettings["LangInstallation"];

                Thread.CurrentThread.CurrentCulture =
                Thread.CurrentThread.CurrentUICulture = new CultureInfo(lang);

......
                   db.LogicalStates.Add(new LogicalState { Id = 1, Description = Resources.Global.Active, BackgroundColor = "#00ff00", FontColor = "#ffffff" });
......



Ora invece con il servizio da registrare, come faccio nel mio OnModelCreating a settare custom un lingua e fare il seed dei dati recuperandoli dal resource?
    protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.Entity<TypeInstrument>().HasData(new TypeInstrument() { Id = 1, Description = "RECUPERO DA RESOURCE" } );
Modificato da fractals87 il 12 luglio 2019 15:45 -
RispondiQuoting
BrightSoul
BrightSoul
il 12 luglio 2019 alle 15:26
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao, grazie!
Ho bisogno che tu mi chiarisca meglio la situazione. Il vantaggio principale di usare un file di risorse è che permette di recuperare le stringhe localizzate in maniera molto più rapida rispetto a un database perché i file di risorse vengono compilati in assembly e caricati in memoria RAM. Lo svantaggio, invece, è che bisogna ricompilarli ogni volta che un testo deve cambiare.

Quindi, le migliori candidate ad essere inserite in file di risorsa sono le stringhe poco mutevoli, come le voci di menu, i messaggi di errore e di conferma e così via. Puoi anche inserirci i nomi e le descrizioni dei prodotti, ma solo nel caso in cui il catalogo non sia troppo mutevole e non ci sia il requisito di modifica da un backoffice di gestione.

Datto questo, perché vuoi leggere le stringhe dal file di risorsa per inserirle in un database, rinunciando così al loro vantaggio principale? Tu hai il requisito di rendere modificabili le stringhe localizzate? In questo caso va bene inserirle nel database, ma poi dovresti avvalerti di un meccanismo di caching per evitare di inviare decine o centinaia di richieste al database, che affosseranno le prestazioni della tua applicazione. In questo caso dovrai realizzare un'implementazione di IStringLocalizer completamente diversa, che si avvalga del servizio IMemoryCache per recuperarle dalla cache (e di un DbContext quando in cache non esistono).

ciao,
Moreno
Modificato da BrightSoul il 12 luglio 2019 15:30 -
Enjoy learning and just keep making
RispondiQuoting
fractals87
fractals87
il 12 luglio 2019 alle 15:39
80 messaggi dal 17 maggio 2011
Intanto grazie della celere risposta.

Nel mio caso ci sono una serie dati (principalmente enumerati) che finiscono nel database.
(Questo per fornire una configurazione di base all'applicativo).

Ipotesi :
CategoriaProdotti

1 - Calzini
2 - Mutande

Il mio desiderio sarebbe recuperare la stringa dal resource per fare la prima "installazione" con dati di seed della lingua.

Poi l'utente finale ha la possibilità di introdurre altre categoria, che ovviamente inserirà nella lingua che gli appartiene.

Tutta questa bidone di informazioni non mi serve sia multilingua in quanto sono dati in input dell'utente.
RispondiQuoting
BrightSoul
BrightSoul
il 12 luglio 2019 alle 16:20
11.886 messaggi dal 09 febbraio 2002
Contributi

Poi l'utente finale ha la possibilità di introdurre altre categoria

Ok, in questo caso il file di risorse non serve. Potresti mettere i testi localizzati direttamente nella migration, cablati nel codice C# come vedi qui:
https://docs.microsoft.com/it-it/ef/core/modeling/data-seeding#manual-migration-customization

Personalmente non sono un fan del metodo HasData perché tendenzialmente porta a mischiare dati e definizione del modello, tutto dentro il DbContext. Comunque, se a te piace lo puoi usare.

ciao,
Moreno
Enjoy learning and just keep making
RispondiQuoting
gianx10
gianx10
il 4 settembre 2019 alle 09:57
19 messaggi dal 14 gennaio 2008
Ciao Moreno, ottimo articolo
Una domanda: x non "sporcare" le firme dei controller, io attraverso DI userei il costruttore della classe; se però ho diversi layer sottostanti il controller, come il Biz ed il Dal, come faccio a far arrivare a queste dll, il mio IStringLocalizer? Devo usare in ogni strato il relativo costruttore come sul Controller?
RispondiQuoting
BrightSoul
BrightSoul
il 4 settembre 2019 alle 15:06
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao, grazie!


come faccio a far arrivare a queste dll, il mio IStringLocalizer? Devo usare in ogni strato il relativo costruttore come sul Controller?

Sì. Manifestare le dipendenze nel costruttore è un buon design perché:
  • 1. È un approccio pragmatico, dato che rende evidente che la classe ha bisogno di altri servizi per funzionare. Infatti, non la si potrebbe neanche costruire se non fornendo tutti i parametri che richiede nel costruttore;
  • 2. Rende la classe testabile in isolamento perché puoi fornirgli dall'esterno degli oggetti mock che ti permettono di verificare come si comporta in varie situazioni, da quelle più comuni a quelle limite.


Se registri le classi del tuo BL e del tuo DAL per la dependency injection non ti dovrai preoccupare tu di crearne delle istanze e fornire i valori per tutti i parametri del suo costruttore. Così, se necessiti dell'IStringLocalizer in una classe del tuo BL, dovrai riceverlo nel costruttore solo di quella classe e non passarlo in giro per l'applicazione.

L'interfaccia IStringLocalizer è definita nel pacchetto NuGet Microsoft.Extensions.Localization.Abstractions, che non ha altre dipendenze, quindi la puoi referenziare tranquillamente anche dai progetti BL e DAL. Se non ti piace l'idea di avere una dipendenza da quel pacchetto, puoi costruirti una tua interfaccia tipo IMioLocalizzatore che si risolverà con un'implementazione concreta che wrappa l'IStringLocalizer e di fatto lo nasconde al BL e al DAL.

ciao,
Moreno
Modificato da BrightSoul il 04 settembre 2019 15:07 -
Enjoy learning and just keep making
RispondiQuoting
pfornari
pfornari
il 21 aprile 2020 alle 19:00
6 messaggi dal 09 dicembre 2007
Ciao, grazie per l'articolo.

Mi stavo chiedendo se esiste un modo tipizzato di estrarre le stringhe, come faresti accedendo direttamente al file di risorse quando genera il codice nel file .Designer.
La proprietà generata in questo modo del file di risorse ha anche un comodissimo commento xml che dà una preview del valore della risorsa.

Cioè, mi piacerebbe scrivere:
localizer.Title
al posto di
localizer["Title"]

Avrebbe delle controindicazioni questo approccio ?
Grazie
RispondiQuoting
Nemo2099
Nemo2099
il 10 settembre 2020 alle 10:44
1 messaggio dal 04 febbraio 2020
Ciao,
grazie mille per la guida. Sto provando ad implementare la localizzazione dei testi come indicato, ma quando vado a creare la classe CustomLocalizer derivata da IStringLocalizer una sua implementazione mi viene indicata come obsoleta. Più precisamente la "public IStringLocalizer WithCulture(CultureInfo culture) => localizer.WithCulture(culture);". C'è un modo per ovviare alla cosa? Qual è l'approccio ora corretto?
Grazie!
Modificato da Nemo2099 il 11 settembre 2020 09:43 -
RispondiQuoting

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.