Patrón de Inyección Setter o contexto ambiental

Question

Tengo algunos componentes globales No estoy seguro de cómo ponerlos en el diseño. Tales como:

• Ajustes clase: una operación de interfaz los ajustes iniciales del programa, se podría App.config (1way), web.config (1way), valores codificados duro (1way), o sqldb (2way) detrás de las escenas.

• clase Idioma: que contiene diferentes grupos de idiomas, y de nuevo, podría haber algunos archivos resx (1way), los valores no modificables (1way) o sqldb (2 vías) detrás de él.

primera pregunta es, ¿debería hacer estas propiedades clases Setter en la inyección de dependencias (yo uso Windsor):

public ISettings Settings {set;} 
public ILanguage Language {set;} 

o debería ellos hacer contexto ambiental:

string DoSomethingAndReportIt() { 
    //do something ... 
    var param = Settings.Current.SomeParam; 
    //report it ... 
    return Language.Current.SomeClass_SomeMethod_Job_Done; 
} 

I Observe que hay algunos componentes en la biblioteca .net que en realidad usan un patrón de contexto ambiental, por ejemplo System.Security.Principal, System.Web.ProfileBase, System.Thread.CurrentCulture ...

¿Cree que no es perjudicial hacer que mis clases globales, como Configuración e Idioma, sean clases de contexto ambiental? Si no, ¿por qué se prefiere DI? ¿Toman más ventaja en las pruebas unitarias en comparación con el ambiente?

La segunda pregunta es, si DI es mejor, (tengo la sensación de que se prefiere el patrón DI), ¿cuál es una buena forma de proxy de las clases ambientales existentes como Security.Principal o Profile para seguir el patrón DI?

Answer 1

El contexto ambiental es correcto cuando necesita implementar una funcionalidad que abarca múltiples capas. (En su caso, usted dice que los dos objetos son globales). Esta funcionalidad se conoce como crosscutting concerns. Como notó, muchas clases en .NET están implementadas como contexto ambiental, como IPrincipal. Para obtener una versión operativa de su implementación de contexto ambiental, necesitará tener algún valor predeterminado provisto para sus objetos Settings y Language si se desarrollan como contexto ambiental. Mi suposición es que proporcionará una implementación predeterminada de ILanguage y ISettings, y teniendo en cuenta que los usará globalmente, son buenos candidatos para el contexto ambiental.

Por otro lado, ¿con qué frecuencia piensa utilizar esos objetos que implementan estas dos interfaces? Y, ¿la existencia de los dos objetos es crucial, es decir, Settings != null y Language != null? Si realmente desea utilizarlos en una o dos clases, y/o si la existencia de los objetos no es realmente importante, puede optar por la setter injection. La inyección setter realmente no necesita un valor predeterminado, por lo que su objeto puede ser null.

Personalmente, no soy seguidor del contexto ambiental. Sin embargo, lo usaría si resulta ser la solución más aceptable. En el caso de sus implementaciones, haría algo como esto: dado que necesitará inicializar objetos que implementen las dos interfaces una vez y en una sola ubicación, podría comenzar con el contexto ambiental. Si se da cuenta de que lo está utilizando en un número muy reducido de ubicaciones, piense en refaccionarlo como una inyección setter.Si la existencia de objetos es importante, piense en la implementación del constructor.