Przejmująca jednostka MVC 3 jako interfejs

Question

Obecnie pracuję nad projektem MVC 3, używając Ninject jako mojego DI, obiekty biznesowe są przechowywane w oddzielnym zestawie. Występuje problem z parametrami kontrolera, podczas wysyłania z powrotem do operacji CRUD pojawia się błąd "Nie mogę utworzyć instancji interfejsu". Jestem świadomy, że nie można utworzyć instancji interfejsu, ale wydaje się, że jedynym sposobem, w jaki można to obejść, jest użycie niestandardowego modułu wiążącego model i przejście przez FormCollection. Wydaje się to bardzo nieporządne i chcę zachować tak dużo kodu specyficznego dla danego typu, jak to tylko możliwe - stąd interfejsy wszędzie i Ninject do DI konkrety. Nie tylko nietypowe powiązanie modelu wydaje się kłopotliwe - czy nie stracę również swoich DataAnnotations?

Niektóre kodu do opisania tego, co mam:

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); 
} 

ktoś napotkasz tego wcześniej? Jak sobie z tym poradziłeś?

Dzięki!

Answer 1

Dane przekazane do działania kontrolerów są po prostu uchwytami wartości. Nie powinno być w nich żadnej logiki, więc nie ma nic do oddzielenia. Można użyć konkretnych typów (np rekord) zamiast interfejsu (IRecord)

Answer 2

ale wydaje się, że tylko w ten sposób można uzyskać wokół tego jest użycie niestandardowego modelu Binder

model niestandardowy spoiwo to właściwa droga. A przy okazji powinieneś używać modeli widoku jako argumentów akcji, a nie modeli domenowych lub interfejsów.

Nie tylko nietypowe powiązanie modelu wydaje się kłopotliwe - czy nie utracę również swoich danych?

Nie wiem, dlaczego uważasz, że niestandardowy segregator do modelowania może spowodować bałagan. Dla mnie jest to świetny sposób na oddzielenie logiki mapowania na klasę wielokrotnego użytku. I nie, nie stracisz DataAnnotations. Będą działać doskonale na konkretnym przykładzie, który powróci niestandardowy segregator modelu.

Answer 3

Zrobiłem ten sam prosty błąd. Ninject wstrzykuje parametry do twojego konstruktora, ale dodajesz parametry do akcji kontrolera indeksów.

To powinno wyglądać tak:

public class HomeController : Controller 
{ 
    private IRecord _record; 

    public HomeController(IRecord record) 
    { 
     _record = record; 
    } 

    public ActionResult Index() 
    { 
     ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application. " + 
          _record .HelloWorld(); 

     return View(); 
    } 
} 

sens?