Question

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

Answer 1

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