MVC: Create relate entitiy when add one

Question

So, my database now looks like:

Comment -> Commentable 

Commentable -> News
Commentable -> Files
Commentable -> Photo

This mean, when i add new entity (file or photo), i have to add new Commentable and insert this value to entity.

What is the best practise of this? Should i override create function of entities, or put it into repository add function?

Structure of tables looks like so, bcz i don't need to create for each entity own comments table.

Edit: My tables schema like here: One table vs multiple tables in Branko Dimitrijevic post

When i want to add new file or event- at first, i have to generate new "Commentable" row and only after that- add with relate my entity.

So, my question, where i have to put this logic or how to do that in the most correct practise?

Thx.

i afraid i am confused with the question. Can you explain little more detailed please ? — Shyju, Oct 17 '12 at 18:32
I need to add new entity Commentable, when add photo or file or news- so, this means, i have to create at first commentable, get this Id and then set this value as relationship of new file or photo. — user1612334, Oct 17 '12 at 18:47

score 1 · Answer 1 · edited May 23 '17 at 11:56

Think carefully about the design of your photos, news, and files tables. I was thinking through a similar problem when I posted my first Stackoverflow question: Database design - articles, blog posts, photos, stories.

I realized that Articles, Photos, Videos, Documents, and BlogPosts all shared some common fields, like Author, ReleaseDate, Title, Description, Keywords, and so on. So I created a super-type/sub-type hierarchy of tables, using EF's type inheritance features to model this. Then comments have a foreign key only to one super-type talbe (which I named Publications). This has worked quite well for me, for the most part.

Beware if you use EF's inheritance: there are 2 variants: Table-per-type (TPT) and Table-per-heirarchy (TPH), each with issues:

TPT: provides a super-table for the common fields, and a separate DB table for the propterties of each sub-type. This has performance issues (sometimes severe) when you query against the super-type. A work-around is to create a view to reference the super-type table as a different entity (which is what I did), but it's a little messier than you'd like

TPH: has no performance issues, but the solution essentially flattens the hierarchy into one table. DBAs and DB purists, I've found, really don't like you to do this.

score 0 · Answer 2 · answered Oct 17 '12 at 18:59

You don't need to do that. EF will do that if you have the correct model structure.

public class Comment
{
  public int ID { set;get;}  
  public string Author { set;get;}
  public IEnumrable<CommentContent> CommentContents
}
public class CommentContent
{
  public int ID { set;get;}  
  public string Photo { set;get;}
  public string News{ set;get;}
  public int CommentID { set;get;}
}

Now have your model set with properties (including child) and execute SaveChanges and EF will take care of setting the parent IDs on child table.

var model=new Comment();
model.Author="Scott";
model.CommentContents.Add(new CommentContent
                                 { Photo="abc.jpg", News="Some content"});
model.CommentContents.Add(new CommentContent
                                 { Photo="abc3.jpg", News="Some content2"});
yourDbContext.Comments.Add(model);
yourDbContext.SaveChanges();

I'm sorry, but my database structure like here on image: http://stackoverflow.com/questions/10602562/one-table-vs-multiple-tables — user1612334, Oct 17 '12 at 19:10

score 0 · Answer 3 · edited May 23 '17 at 12:18

It probably helps to know the "official" term for what you're trying to achieve, so you may be able to do further research. It is polymorphic associations. Note that it is generally considered an anti-pattern. I once asked a question about them here at StackOverflow and the first image in it may be the way for you to implement it:

enter image description here

This is according to Bill Karwin's recommendation in how to implement this anti-pattern if you use it anyway (as I do myself, as for me, it's just a pattern).

In fact, this is like Faust's TPT solution (which you should accept as answer if it works for you), especially if you extend the base table with all properties that the three classes have in common.

In this case I would prefer to handle it in repository Add functions, in each of which the comment object is created for the entity you add.

MVC: Create relate entitiy when add one

3 Answers3