2009-12-02 6 views
5

En mi búsqueda eterna de aspirar menos Actualmente estoy viendo mi turbina mvc para hacer el trabajo sucio de IoC.
Estoy usando el ejemplo de la cena mvc Turbine nerd como protagonista y las cosas parecen bastante lógicas hasta el momento. Aunque me estoy refiriendo al proyecto de la turbina aquí, supongo que la filosofía detrás de esto es algo general para el patrón Seguro para leer y el raro podcast, soy nuevo en el concepto de IoC y tengo algunas preguntas.¿Dónde guardar cosas como las conexiones en un patrón de IoC?

hasta ahora tengo una entrada para cada IServiceRegistration IRepository Quiero registrar
Por ejemplo:

public class UserRepositoryRegistration : IServiceRegistration 
{ 
    public void Register(IServiceLocator locator) 
    { 
     locator.Register<IUserRepository, UserRepository>(); 
    } 
} 

La aplicación concreta de la IUserRepository necesita alguna configuración sin embargo. Algo así como una cadena de conexión o en este caso una ruta al archivo db4o para usar.

¿A quién ya quién debo suministrar esta información?

Respuesta

3

Tanto Robert como Lucas dieron en el clavo con sus respuestas. Todas las "cosas adicionales" para la cuenta vivirían dentro de la clase UserRepository. Esta es actualmente la forma en que se implementa la Turbine ND.

Sin embargo, nada le impide la creación de una nueva clase llamada ConnectionStringProvider que luego pueden ser 'inyecta' en su UserRepository que proporcionará la cadena de conexión (ya sea codificado o lee de un archivo de configuración.

El código puede ser de la siguiente manera:.

public class ConnectionStringProvider { 
    public string ConnectionString { 
     get{ 
      // your impl here 
     } 
    } 
} 

public class UserRepository { 
    public UserRepository(ConnectionStringProvider provider){ 
     // set internal field here to use later 
     // with db connection 
    } 
} 

a partir de aquí, se agrega un registro para ConnectionStringProvider dentro de la clase UserRepositoryRegistration y la turbina se encargará del resto para usted

+0

Gracias, eso es una buena solución Aunque mi. Al principio parece que se trata de algo demasiado complejo, actualmente tengo mis conexiones en archivos web.config, pero se están haciendo planes para tener todas las configuraciones de todas nuestras aplicaciones en una base de datos y dar a las aplicaciones solo una referencia a esa base de datos. Entonces preferiría que las cosas de configuración fueran conectables. –

+0

También gracias por suscribirse para responder esto. Espero que disfrutes tu estadía en SO –

2

En general, esto es únicamente la preocupación del UserRepository concreto que requiere la cadena de conexión o la ruta de la base de datos. Haría muy bien abandonando la ruta en el archivo de configuración de la aplicación y haciendo que su repositorio concreto extraiga los datos de configuración directamente.

No todos los repositorios van a requerir esta información, que es una de las razones por las que tiene la abstracción en primer lugar. Por ejemplo, un rápido en memoria concreta IUserRepository no requerirá una ruta a la base de datos o probablemente ninguna configuración adicional funcione.

1

Similar a Robert, recomendaría poner esto en el archivo de configuración de la aplicación, sin embargo, con entradas específicas para cada tipo de inyección. De esta forma, su cadena de conexión o ruta se puede personalizar con cada inyección.

Cuestiones relacionadas