Actualmente estoy trabajando en un proyecto de MVC 3 usando Ninject como mi DI, los objetos comerciales se almacenan en un ensamblaje separado. Me encuentro con un problema con los parámetros del controlador, cuando vuelvo a publicar para las operaciones de CRUD me sale el error "No se puede crear una instancia de una interfaz". Soy consciente de que no puede crear una instancia de una interfaz, pero parece que la única manera de evitarlo es usar una carpeta de modelo personalizada y pasar la FormCollection. Esto parece realmente desordenado y quiero mantener la mayor cantidad posible de códigos de tipo del proyecto, por lo que puedo interactuar en todas partes con Ninject y resolver los concretos. No solo el encuadernado de modelo personalizado parece desordenado, ¿no perderé también mis Anotaciones de datos?Entidad que pasa MVC 3 como interfaz
algo de código para describir lo que tengo:
public ActionResult Create()
{
// I'm thinking of using a factory pattern for this part
var objectToCreate = new ConcereteType();
return (objectToEdit);
}
[HttpPost]
public ActionResult Create(IRecord record)
{
// check model and pass to repository
if (ModelState.IsValue)
{
_repository.Create(record);
return View();
}
return View(record);
}
Alguien ha funcionado en esto antes? Como lo superaste?
Gracias!
¿No estaría yo rompiendo la regla del acoplamiento flojo? ¿Qué ocurre si quiero/tengo que cambiar el nombre de mi método concreto por alguna razón, es decir, el registro se convierte en RecordDifferent? Puedo tener RecordDifferent implementando IRecord y cambiar mi DI para ahora inyectar RecordDifferent en todos los casos de IRecord. –
Prefiero usar clases para contenedores modelo y herencia en lugar de interfaces. Por defecto DI no se usa para crear objetos pasados a acciones. Utilizo DI solo para la lógica real, no para los contenedores de datos. – Novakov
Realmente no entendí lo que quería decir inicialmente, pero después de haber progresado un poco con este proyecto ahora me di cuenta de que estoy tratando de "desacoplar" contenedores de datos simples como usted dijo. No existe ningún comportamiento (todavía) en ninguno de los objetos POCO que mapean una tabla de base de datos y, por lo tanto, no hay razón para interactuar con ellos, ni utilizar una fábrica para crear instancias de ellos. Creo que lo que tuve problemas para entender es que el desacoplamiento debería usarse realmente para objetos con comportamiento en lugar de simplemente propiedades de datos. –