Question

after several attempts and some searching I finally decided to try it here.

Short story: I have created quite a ‘normalized’ database design for content management system application and now I am trying to map it to EF entities.

I have M:N relationship between Pages and their content (ContentVersion table) – connected by table Content. This is because the application is multilingual and I am going to store recent history of content edits.

Now, I could just create DbContext from my db, scaffold few controllers and have a solid base, but there would be a problem with that. When I would try to create new Page, I would be allowed to basically enter just a Title and Slug, but there would be no content for that page. I can of course connect that somehow with other entities and make some hierarchical business logic that would be updating several entities every time, but I first wanted to try a bit more abstract approach.

I think I basically need entity splitting over 3 related tables. I want to create an entity (let’s call it FinalPage), that could be used to work with page as one piece -> use it to scaffold controllers etc.

FinalPage is something that user fills up when creating a new Page, so it would contain:

Title (from Page entity)
Slug (from Page entity)
TemplateId (from Page entity)
LanguageId (from Content entity)
Title (from ContentVersion entity)
Body (from ContentVersion entity)
+ other related fields from ContentVersion entity

When I would generate ‘create new’ page for it, I would fill everything and everything would get saved into appropriate tables.

I tried creating new entity in my entity model, mapping properties to different tables.. tried several approaches, but never got working solution. Mostly because of typical ‘you need to map every key’ error. I was checking this post from Rob Bagby, but he was connecting just two tables, that shared same key.

I also tried something what felt really silly… creating entity (entA) from Page and Content entities – connected by PageId property. And creating second one (entB) from Content and ContentVersion – connected by ContentId. Then I wanted to create third (entC) that would connect entA and entB. That also didn’t work (and I am actually glad, because that would be really weird solution).

I feel like I am:
a.) Missing something obvious.
b.) Having a bad database design.
c.) Wanting too much from EF.

Any help is welcomed.
– If you see something terrible in the database design, please let me
know.
– If you know, how to achieve my goal, please share.
– If you have experience with this type of apps and have better solution,
I would like to hear about it.

I am also basically looking for some best-practices.

Answer 1

Sounds like you’re trying to make your ORM fit your UI model, which is not the way to do it. You should create a new class that represents the data you want to capture from a form, and then process that into the various table as required. So your model that would be used when creating a new page would be something like this:

public class FinalPage{
    public string Title { get; set; }
    public string Slug { get; set; }
    public string Body { get; set; }
    public int TemplateId { get; set; }
    public int LanguageId { get; set; }
}

When the user submits the form (you’ve not mentioned what UI you’re using) you would process those values into the various ORM objects.

public void SaveData(FinalPage model){
    var page = new Page{
        Title = model.Title,
        ...
    };
    db.Pages.Add(page);

    var contentVersion = new ContentVersion{
        Body = model.Body,
        ...
    };
    db.ContentVersions.Add(contentVersion);

    ...
}

This is the difference between a View Model and a Database Model, the do not have to be the same, and the business logic is applied between the two entities. An alternative to this, which I have used in a previous project is to have a class that contains the ORM objects that you want to use, this way you get the DataAnnotation validation stuff in your UI.

public class FinalPage{
    public Page Page { get; set; }
    public ContentVersion ContentVersion { get; set; }
    public Content Content { get; set; }
}

Then display the appropriate fields from each of the inner objects. In MVC4 with Razor:

@Html.EditorFor(m=>m.Page.Title)

This will produce the validation errors that you expect, and that are defined in the data model, however you need to be aware that you may need to ensure that the objects are handled correctly later (for instance in MVC your ModelState will nearly always be Invalid). Personally I would recommend the first approach as this is the traditional method for operating with differing UI and ORM models. The general rule I go with is, use the ORM model if you can, but as soon as it becomes a little tricky, switch to a ViewModel class to represent your values.