MVC, DI (inyección de dependencia) y creación de instancia de modelo desde el controlador

Question

Mi despachador está "seleccionando" el controlador correcto; luego se crea la instancia del Controlador (DependencyInjectionContainer se pasa al constructor del Controlador); a continuación, llamar al método de algún controlador ...

class UserController extends Controller 
{ 

    public function __construct(DependencyInjectionContainer $injection) { 
    $this->container = $injection; 
    } 

    public function detailsAction() { 
    ... 
    } 

} 

DependencyInjectionContainer contiene adaptador DB objeto, objeto de configuración, etc. Ahora vamos a ver lo que() método contiene detailsAction ...

public function detailsAction() { 

    $model = new UserModel(); 
    $model->getDetails(12345); 

} 

Como se ve I' m creando una nueva instancia de UserModel y llamando a los métodos getDetails. El método getDetails() del modelo debe conectarse a db para obtener información sobre el usuario. Para conectarse a DB, UserModel debe poder acceder al adaptador DB.

¿Cuál es la forma correcta de pasar DependencyInjectionContainer al UserModel? Creo que de esta manera está mal ...

public function detailsAction() { 

    $model = new UserModel($this->container); 
    $model->getDetails(12345); 

} 

Answer 1

En lugar de inyectar todo el DI Container en sus clases, debe inyectar solo las dependencias que necesite.

Su UserController requiere un adaptador de base de datos (vamos a llamar a esta interfaz IDBAdapter). En C# esto podría tener este aspecto:

public class UserController 
{ 
    private readonly IDBAdapter db; 

    public UserController(IDBAdapter db) 
    { 
     if (db == null) 
     { 
      throw new ArgumentNullException("db"); 
     } 

     this.db = db; 
    } 

    public void DetailsAction() 
    { 
     var model = new UserModel(this.db); 
     model.GetDetails(12345); 
    } 
} 

En este caso estamos injectiing la dependencia en el UserModel.En la mayoría de los casos, sin embargo, tendería a considerar un olor DI si el UserController solo toma una dependencia para pasarlo, por lo que un mejor enfoque podría ser que UserController dependa de una fábrica abstracta como esta:

public interface IUserModelFactory 
{ 
    UserModel Create(); 
} 

en esta variación, el UserController podría tener este aspecto:

public class UserController 
{ 
    private readonly IUserModelFactory factory; 

    public UserController(IUserModelFactory factory) 
    { 
     if (factory == null) 
     { 
      throw new ArgumentNullException("factory"); 
     } 

     this.factory = factory; 
    } 

    public void DetailsAction() 
    { 
     var model = this.factory.Create(); 
     model.GetDetails(12345); 
    } 
} 

y se podía definir un UserModelFactory concreta que se lleva a una dependencia de IDBAdapter:

public class UserModelFactory : IUserModelFactory 
{ 
    private readonly IDBAdapter db; 

    public UserModelFactory(IDBAdapter db) 
    { 
     if (db == null) 
     { 
      throw new ArgumentNullException("db"); 
     } 

     this.db = db; 
    } 

    public UserModel Create() 
    { 
     return new UserModel(this.db); 
    } 
} 

Esto le da mejor separación de preocupaciones.

Si necesita más de una dependencia, simplemente inyéctelas a través del constructor. Cuando comienza a obtener demasiados, es una señal de que está violando el Single Responsibility Principle, y es hora de refactor to Aggregate Services.

Answer 2

que haría uso de un objeto único para todos los parámetros de configuración: Se configura en su arranque, y luego optar por utilizar directamente o pasarlo como parámetro en tus objetos

La idea es tener un método completo para recuperar sus datos de configuración.

Puede proporcionar una clase abstracta para la manipulación de db que utiliza su configuración. semifallo. DependancyInjection aún se puede usar para anular sus datos predeterminados.

El enlace de arriba en el comentario (posible 'duplicado') concluye sobre el uso de la inyección de constructor: está cerca de su método actual.

Sin embargo, si trato de entender cómo funciona su modelo, supongo que tendrá muchas otras clases de modelos además de "userModel". Por lo tanto, una clase abstracta que use un singleton de configuración podría ser una buena solución: todas las próximas clases de modelo ampliarán esta clase abstracta y no tendrá que preocuparse por su configuración.

Por otro lado, su solución es buena para mí siempre que su dependendanceInjectionContainer cambie con frecuencia.