MVC 3: Using EF generated classes as strongly-typed models

Question

Following on from this question, I'm using a simple ViewModel class to test passing a strongly-typed model to a view. Whilst Darin's answer to my original question has solved the problem I had, it's now left me scratching my head as to why I can't do the same thing with an EF generated class. Here's what I have:

public ActionResult Test()
{
    using (MyEntities db = new MyEntities())
    {
        var model = from c in db.Categories
                    select new CategoryViewModel { CategoryID = c.CategoryID, Name = c.Name };

        return View(model.ToList());
    }
}

This is CategoryViewModel:

public class CategoryViewModel
{
    public int CategoryID { get; set; }
    public string Name { get; set; }
}

In my view I'm simply foreaching over the model. This produces the desired results. However, one of the classes that was generated for me by EF, is Category. I was initially trying to use it to build the strongly-typed model and pass that to the view instead, like so:

public ActionResult Test()
{
    using (MyEntities db = new MyEntities())
    {
        var model = from c in db.Categories
                    select new Category { CategoryID = c.CategoryID, Name = c.Name };

        return View(model.ToList());
    }
}

This was giving me the following error:

"The entity or complex type 'MyProjectModel.Category' cannot be constructed in a LINQ to Entities query."

So my question is, what is the difference between CategoryViewModel and Category other than Category being generated for me? What is preventing me from using Category as my model type in this scenario? I've been looking through other questions (and answers) on SO today but I've been unable to find something that discusses this. I've also seen a few other new terms mentioned in those posts (buddy classes, automappers, POCO) but it seems premature to look into what they are without understanding the foundation of my problem.

I'd really appreciate some insight.

Nathan Anderson · Accepted Answer · 2011-06-21T17:19:04.867

Though I don't know exactly why I bet that the entity framework doesn't like selecting new objects of the same type in the property you are writing your query off of. If my assumption is correct the following code should be equivalent to what you are trying to do:

public ActionResult Test()
{
    using (MyEntities db = new MyEntities())
    {
        var model = from c in db.Categories;

        return View(model.ToList());
    }
}

You would only need to select new objects when you are mapping the properties of your context's classes to another class (IE not one that is generated by the EF).

I did a little more research into the issue, including duplicating it myself, according to the stack trace this is where the exception is thrown: System.Data.Objects.ELinq.ExpressionConverter.CheckInitializerType(Type type) Here is the source code for CheckInitializerType (found here):

 // Determines whether the given type is supported for materialization
    private void CheckInitializerType(Type type)
    {
        // nominal types are not supported
        TypeUsage typeUsage;
        if (_funcletizer.RootContext.Perspective.TryGetType(type, out typeUsage))
        {
              BuiltInTypeKind typeKind = typeUsage.EdmType.BuiltInTypeKind;
              if (BuiltInTypeKind.EntityType == typeKind ||
                  BuiltInTypeKind.ComplexType == typeKind)
              {
                  throw EntityUtil.NotSupported(System.Data.Entity.Strings.ELinq_UnsupportedNominalType(
                            typeUsage.EdmType.FullName));
              }
        }

        // types implementing IEnumerable are not supported
        if (TypeSystem.IsSequenceType(type))
        {
             throw EntityUtil.NotSupported(System.Data.Entity.Strings.ELinq_UnsupportedEnumerableType(
                        DescribeClrType(type)));
        }
   }

For reasons I haven't determined yet, if the object you are trying to project properties onto has the BuiltInTypeKind of EntityType or ComplexType, then projection is not supported. With my testing I discovered that I can project properties onto an entity that was generated with another edmx file, so the relationship with a given ObjectContext seems to boil down to the System.Data.Objects.DataClasses.EdmEntityTypeAttribute that decorates the generated Entity class.

Hi Nathan, that does actually work but it retrieves all the data from the table. What I wanted, although my example here doesn't show this, is to select just a few columns and return their data. I have a much larger Articles table which has a lot of fields in it and there are times where I only need a couple of them. I didn't want to pull unnecessary data from the database. I was using the Category table as a simple test. :) — John H, Jun 20 '11 at 15:01
I think I understand what you're trying to do, but it seems the crux of your issue is still selecting a new object that is generated by EF. If you only need a few columns you are probably best off with using a another class with only those properties you are concerned with (or at least just restrict it to the objects you are interested in, like `var model = from c in db.Categories where c.IsActive select c;` - at least that will just return the rows that meet your conditions. — Nathan Anderson, Jun 20 '11 at 15:51
Thanks Nathan. Sorry for the slow response. I appreciate your answer and the comments but I'm reluctant to accept your answer because it still doesn't tell me why this is the case. — John H, Jun 21 '11 at 15:29
I did a little more research into the issue and have updated my answer with some more information on the issue, and at least explains why it is happening (as best as I can tell at this point) — Nathan Anderson, Jun 21 '11 at 17:20
After doing some extra research after your updated answer, I cannot seem to find why exactly this isn't supported. However, it seems to be more of an API design decision rather than something for me to worry about. My main concern was with generating extra classes which effectively breaks the DRY principle. In any case, after spending that extra time looking into this, I believe your answer to be as accurate as possible, so I've accepted it. Thanks! — John H, Jun 24 '11 at 18:20

MVC 3: Using EF generated classes as strongly-typed models

1 Answers1