Code First - adding to related "tables" in the model?

Question

I have something like this

public class Adult
{
    public int AdultId { get; set; }
    public string Name { get; set; }

    public virtual IEnumerable<NicknamedKid> NicknamedKids { get; set; }
}

public class Child
{
    public int ChildId { get; set; }
    public string Name { get; set; }
}

public class NicknamedKid 
{
    public int AdultId { get; set; }
    public int ChildId { get; set; } 
    public string Nickname { get; set; }
}

My question is, if I want to create and add a new NicknamedKid to an Adult, would I put the method to add the NicknamedKid on the Adult class, or some AdultRepository class? And, if I add it to the Adult class, does that mean that class would have to know the Repository class to add it?

I guess that I am confused as to how much the Model should know about the Data layer. I am thinking the Model should be able to handle its own layer, and not know about any Repository or DbContext, but I assume that's not advisable (or possible)?

Answer 1

I blame Microsoft. That's generally a safe stance, anyways, but particularly here, they've really mangled the terminology. You have a framework called MVC, which obviously enough is modeled after the pattern of MVC, and they give you folders in your project called "Models", "Views", and "Controllers", appropriately enough. Where they screwed up is in creating sample projects where they fill the "Models" folder with entities, which are not models.

If you come from another MVC framework, like Ruby on Rails or Django, you're used to the concept of a model that is persisted and also is the repository for that persisted data. Microsoft, however, did not go this direction with MVC, instead you get an entity, with no guidance on what is or how to set up your model. The natural assumption is that the entity, then, is the model, which, as it did in your case, only serves to confuse.

So what's an entity? It's essentially just a DTO, a Data Transfer Object. It's a class representation of a database table that serves merely as some place for Entity Framework to stuff the data it retrieves. Your "model" from the MVC pattern, actually ends up in practice being an amalgamation of your repositories/services (the DAL) and your view models, which are actually closer to the concept of a model on their own than the entity.

To answer your question, then, no, Adult should not be responsible for adding a NicknamedKid, nor should it have any reference to Entity Framework or any repository. It should hold only the data that is persisted and any application logic necessary for persistence.

Also, as long as we're here, NicknamedKid should not have a reference to Adult, regardless, nor should Adult know about NicknamedKid. Adult references Child, and even though you didn't set it up this way (yet), NicknamedKid is really just a subclass of Child. You've essentially just manually implemented TPT (table per type) inheritance between Child and NicknamedKid without actually having one inherit from the other. Nickname is really just a property of a specific type of Child (namely, one that has a nickname. Regardless, though, you should never have an entity that has a foreign to two other entities that already have foreign keys to each other. If you need to get at NicknamedKid from Adult, you can do that through Child. There's no need for a separate relationship.