Estoy utilizando MVC3, Entity Framework v4.3 Code First y SimpleInjector. Tengo varias clases simples que se ven así:Cómo reducir el número de dependencias inyectadas en el controlador
public class SomeThing
{
public int Id { get; set; }
public string Name { get; set; }
}
tengo otra entidad que tiene este aspecto:
public class MainClass
{
public int Id { get; set; }
public string Name { get; set; }
public virtual AThing AThingy { get; set; }
public virtual BThing BThingy { get; set; }
public virtual CThing CThingy { get; set; }
public virtual DThing DThingy { get; set; }
public virtual EThing EThingy { get; set; }
}
Cada cosita (actualmente) tiene su propio encargado, de este modo:
public class SomeThingManager
{
private readonly IMyRepository<SomeThing> MyRepository;
public SomeThingManager(IMyRepository<SomeThing> myRepository)
{
MyRepository = myRepository;
}
}
Mi MainController en consecuencia sigue:
public class MainController
{
private readonly IMainManager MainManager;
private readonly IAThingManager AThingManager;
private readonly IBThingManager BThingManager;
private readonly ICThingManager CThingManager;
private readonly IDThingManager DThingManager;
private readonly IEThingManager EThingManager;
public MainController(IMainManager mainManager, IAThingManager aThingManager, IBThingManager bThingManager, ICThingManager cThingManager, IDThingManager dThingManager, IEThingManager eThingManager)
{
MainManager = mainManager;
AThingManager = aThingManager;
BThingManager = bThingManager;
CThingManager = cThingManager;
DThingManager = dThingManager;
EThingManager = eThingManager;
}
...various ActionMethods...
}
En realidad, hay dos veces más dependencias inyectadas en este controlador. Huele. El olor es peor cuando también sabe que hay un Otro Controlador con todas o la mayoría de las mismas dependencias. Quiero refactorizarlo.
Ya sé lo suficiente sobre DI para saber que la inyección de propiedades y el localizador de servicios no son buenas ideas.
No puedo dividir mi MainController, porque es una sola pantalla que requiere que todo esto se muestre y editable con solo hacer clic en el botón Guardar. En otras palabras, un único método de acción posterior lo guarda todo (aunque estoy dispuesto a cambiarlo si tiene sentido, siempre que siga siendo un solo botón Guardar). Esta pantalla está construida con Knockoutjs y se guarda con publicaciones de Ajax si eso hace la diferencia.
Me gustó el uso de un contexto ambiental, pero no estoy seguro de que sea el camino correcto. Me complació el uso de inyectar una fachada también. También me pregunto si debería implementar una arquitectura de comando en este punto. (¿No todo lo anterior simplemente mueve el olor a otro lado?)
Por último, y tal vez independiente de los tres enfoques anteriores, ¿debería tener un único, por ejemplo, LookupManager con métodos explícitos como GetAThings() , GetAThing (id), GetBThings(), GetBThing (id), y así sucesivamente? (Pero luego ese LookupManager necesitaría varios repositorios inyectados en él, o un nuevo tipo de repositorio.)
Dejando de lado mis reflexiones, mi pregunta es, para reiterar: ¿cuál es una buena manera de refactorizar este código para reducir el número loco de ¿dependencias inyectadas?
posible duplicado de [Cómo tratar la sobreinyección del constructor en .NET] (http://stackoverflow.com/questions/4603555/how-to-deal-with-constructor-over-injection-in-net) – Steven