asp.net mvc - Update/pass objects with no association between controller and view

Essentially what I have is an entity class (Article) and one article may belong to n categories. This is where one would expect a field for the categories (say an ICollection) but the database is not built that way and I cannot modify the Entity Framework model.

When a category is selected in the view, the user has to select a property (a string list between 1 to 10. It will look like this:

 Category         Option
===============================
[x] Category 1   |---------|v|
[x] Category 2   |---------|v|
[x] Category 3   |---------|v|
[x] Category 4   |---------|v|

[x] - checkbox
|---|v| - dropdown list

However I'm thinking that perhaps I could create a ViewModel for this particular case. I was thinking something like

namespace Models.ViewModels
{
    public class ArticleViewModel
    {
        public Article Article { get; set; }
        public ICollection<Category> Categories { get; set; }

        public ArticleViewModel()
        {
            Categories = new List<Category>();
        }
    }
}

However when I post the form to the controller the ArticleViewModel and all of its internals are null. I'm not sure why.

The view itself is pretty basic, it will have two separate forms: one for modifying article details and one for assigning categories to the article.

As a guy new to asp.net mvc, I find it a little difficult to wrap my head around this problem.

Which approach would you recommend?

Update: added code for the view.

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<Models.ViewModels.ArticleViewModel>" %>

<asp:Content开发者_如何学Python ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    Modify article: <%= Model.Article.Title %>
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <% using (Html.BeginForm()) {%>
        <%= Html.ValidationSummary(true) %>

        <fieldset>
            <legend>Properties</legend>

            <div class="property">
                <span>
                    <%= Html.LabelFor(model => Model.Article.Title) %>

                    <%= Html.TextBoxFor(model => Model.Article.Title) %>
                    <%= Html.ValidationMessageFor(model => Model.Article.Title) %>
                </span>
            </div>

            <div class="property">
                <span>
                    <%= Html.LabelFor(model => Model.Article.Type) %>

                    <%= Html.TextBoxFor(model => Model.Article.Type) %>
                    <%= Html.ValidationMessageFor(model => Model.Article.Type) %>
                </span>
            </div>

            [continued...]
            <div>
                <%= Html.HiddenFor(model => Model.Article.Id) %>
                <input type="submit" value="Save" />
            </div>
        </fieldset>
    <% } %>
</asp:Content>

Routing looks like this:

routes.MapRoute(
    "Articles",
    "Articles/{action}/{id}",
    new { controller = "Articles", action = "Edit" }
);

---

The whole point of MVC is that your View is decoupled from your Model. It doesn't matter what your EF entities look like.

Create your view and view model classes the way you want. Don't think about your DB structure. If you need a collection of Categories than create it. This code should represent the 'domain' of UI.

In the controller map your view model to EF and vice versa. It's controllers responsibility to understand data access code (or service layer code) and view code.

This approach allows you to take a full advantage of MVC and decoupling between UI and database. Although you end up writing a bit more code for your models it pays up with interest later on (you can modify your db without touching UI and vice versa).

If you find yourself spending a lot of time copying data from EF entities to models than you might want to take a look at this brilliant library: AutoMapper

---

When you set up your view like that, each of those fields is going to have the same name attribute and I don't think MVC will know how to map it back to a single item properly. What does your [HttpPost] action look like? If its anything like:

[HttpPost]
public ActionResult Edit( ArticleViewModel model )
{
  ..
}

then I doubt it will map correctly. You could maybe try accepting List<ArticleViewModel> but I don't think that would work correctly without a CustomModelBinder.

What @Jakub said is correct: de-couple your thinking and design your ViewModel in the most logical way for the view; you can worry about mapping it back to the service layer later. Its a paradigm shift for sure, but one that's worth making. = )