MVC 3 + EF 4.1 + POCOs + ViewModel pattern + Controller with scaffolding == confusion!

I'm [finally!] tackling MVC (version 3) after years of ASP.NET forms development. I have a strong background in n-tier application architecture, and I'm trying to approach this new project properly, with a clear separation of concerns, etc.

What I've done is start out with code-first by creating my POCOs. From this, the framework created my database.

Then, I implemented the Repository pattern by putting all my EF query and CRUD methods in a Repository class for each of my POCO classes in my Models assembly. This way, my Controllers don't need to know a thing about how I access my data via the EF. Great.

Finally, I created a few ViewModel classes in my Models assembly. My intent is, for certain actions (such as create and edit), I reference my ViewModel classes from the RAZOR views, instead of my POCO classes. This way, I can have my POCO class as well as a SelectList for populating a Drop Down within my ViewModel. Both populated by references to the associated Repository classes, which are called from my Controller Actions. I think I'm on a roll now:

class MyObject 
{
    public int ID {get;set}

    [Required]
    [StringLength(512)]     
    public string Name {get;set;}

}

class MyViewModel // ViewModel for a specific view 
{
    public MyObject MyModel {get;set;}        // the model that is being edited 

    // other data the view might need, set by the controller 
    public string SomeMessage { get; set; }
    public List<SomeObject> SomeObjects {get;set;} /// e.g. for a drop-down list

    // My constructor below that populates the "SomeObjects" list, and accepts the
    // "MyObject" class as a parameter in order to set the "MyModel" property above...
    // ..........

}

The Problem...

Before I started using my ViewModel classes from my Controller Create and Edit actions, I passed in the POCO class directly. Everything worked fine when I hit the save button from my Edit form within my view:

Old Code:

[HttpPost]
public ActionResult Edit(MyObject mine) 
{
    if (ModelState.IsValid) 
    {
        myRepository.Update(mine);
        myRepository.SaveChanges();
        return RedirectToAction("Index");
    }
    return View(mine);
}

When I hit save, my POCO class (MyObject) would be returned, automagically populated with values from the form, it would successfully save, and life was peachy.

When I switched to passing in my ViewModel (MyViewModel), everything fell apart.

I was able to refer to my ViewModel (MyViewModel) by setting the @model reference at the top of my Edit view. I was then able to populate my form fields from my POCO class (MyObject) that is part of the ViewModel. I was even able to populate the DropDownList from the SomeObjects collection in the ViewModel and preselect the correct one from my MyObject class I was editing. Everything seemed fine UNTIL...

When I hit the save button and my Controller's Edit ActionResult (POST action) was called,开发者_如何转开发 the MyObject class that is passed in to the ActionResult (public ActionResult Edit(MyObject mine)) was null.

Then, I tried changing the passed in object to my ViewModel (public ActionResult Edit(MyViewModel myVM)), which had the referenced MyObject class (MyModel) as null.

What am I missing?

I know it has to be something so incredibly simple that it's staring me in the face and I cannot see it!

Look at the FormCollection, the names of the keys should match the properties of the class you want to fill. This is how the default modelbinding of MVC works.

Wim,

Thanks so much for your help. I did have s parameter-less constructor, I had just omitted it from the example.

I actually tracked down the issue. In all fairness, the code I typed in was not the actual code since I didn't have it in front of me when I posted this. What the issue was is that my entity model class reference in my ViewModel actually had its set accessor as private:

public MyObject MyModel {get;private set;}

This had prevented the modelbinder from populating that property when posting back during the controller's save method.

What I'm left to do now is to move my validation logic from my EF POCO to my ViewModel, as seems to be the recommended action in this type of pattern.

Thanks for your time, and I hope this helps out other people with similar issues who are new to this framework.