Structuring Resource Files

1

In .NET abbiamo i file di risorse che sono ottimi per consentire la traduzione all'interno dell'applicazione.

In passato ho visto questi file di risorse crescere in elenchi monolitici e non mantenibili di parole e frasi. Qual è il modo migliore per evitare questo?

  • Un singolo file di risorse per l'intera applicazione? È facile da tradurre, ha pochissimi duplicati ma raggiunge dimensioni incredibili
  • Un file di risorse per progetto, questo ha il vantaggio di tenere insieme le risorse e il codice, scompone il file ma crea una possibilità molto maggiore di duplicati tra i file.
  • molti piccoli file. Ad esempio un file di risorse per progetto nel BLL / Dal e uno per Area / Vista nell'interfaccia utente (assumiamo MVC).

Dopo aver faticato a mantenere enormi file di risorse in passato, sono tentato dalla terza opzione. Per creare un singolo per controller / separazione logica nel livello dell'interfaccia utente. Sebbene ciò possa costare di più nella traduzione (e portare a più duplicati) sarà molto più facile da mantenere.

Esiste un altro approccio o consigliato per la gestione dei file di risorse in applicazioni più grandi?

    
posta Liath 30.07.2014 - 14:26
fonte

1 risposta

2

Vorrei utilizzare un file di risorse per progetto (assieme). In questo modo l'assembly può ancora essere riutilizzato senza dipendere dall'applicazione e ha il vantaggio aggiunto che i file delle risorse sono più piccoli. Il rovescio della medaglia è che potrebbe avere alcune duplicazioni per testi come "Sì" e "No", sebbene tu possa scegliere di metterli in un file di risorse condivise (che personalmente non farei). Puoi anche fare riferimento ad altri assembly se un assembly dipende da quelli.

    
risposta data 21.04.2017 - 15:31
fonte

Leggi altre domande sui tag