1

I want to know what is the best way for designing my domain objects for my project.

The domain objects should be ignorant of the ORM/Framework and even the database technology (MySQL, MSSQL, and even Mongo)

And the next question comes in mind, lets say that i have two objects, Post and Comment.

This is the code for the Post object:

class Post {
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public IList<Comment> Comments { get; set; }
}

Now, my question for the Comment object is should it include a Post Id or just a Post object?

class Comment {
    public int Id { get; set; }
    public string Content { get; set; }
    public Post Post { get; set; }

    public int PostId { get; set; } // Should i include it?
}

Is it a good practice to include the Id of the relational object or just its domain object?

Another concern is for no sql database like mongodb. If i store my data in mongodb, what Post object will the Comment object reference? In mongodb there is no relationship between post and comments, any post includes list of comments, but the comments themselves are ignorant of the post they are part of. So what is the best way to make those domain classes compatible both with Sql based database and NoSql databases?

Thank you

Community
  • 1
  • 1
areller
  • 4,800
  • 9
  • 29
  • 57
  • 1
    Do you want to use DDD for your design? You added the DDD tag, but the question seems not to relate to DDD. Please clarify. – theDmi Aug 31 '15 at 08:15
  • Try to avoid that many questions in one question here on SO. The first part of your question (IDs / relations) has nothing to do with the second part (mongoDB), so it would be better if you ask multiple separate questions. – theDmi Aug 31 '15 at 08:17
  • @theDmi that was a mistake, i tried to find a tag for domain objects... I understand that the questions might seem unrelated, but both of the questions revolve around what is the best practice for designing my domain objects. – areller Aug 31 '15 at 08:25
  • "Is if good practice?", well sorry to tell you this but welcome to NoSQL, and therefore whatever works best for you is what is best, and not a standard to follow. On the other hand if you are trying to do something that maps well to both Relational and more Document/Object storage domains, well good luck with that, but you are likely going to need the mapping on both ends from the Relational perspective at least. What is "good practice" is to do what works best for your application. Ideally your objects should be decoupled from storage, but the whole subject is a bit too broad. – Blakes Seven Aug 31 '15 at 08:28

2 Answers2

1

Object-oriented design

You designed your Post and Comment classes in a way that they both reference each other. While I'd try to avoid this tight coupling unless absolutely necessary, it surely makes Comment.PostId obsolete, you can just call Post.Id from within a Comment.

Also, your domain objects should probably try to protect their invariants. What you have now is just property bags (even with public setters), and not domain objects, so currently they don't offer any meaningful advantage over the objects you'd use for persistence.

So if you want to create a domain model, ask yourself questions like these:

  • What can an actor do with a post in the system I'm building?
  • What data on a comment can an actor retrieve?

Then model your domain objects in a way that supports your business cases. For example, if users of your application are prohibited to change the title of a post, you should remove the setter from Post.Title.

This answer may give you more information on the distinction between domain objects and simple property bags (aka POCOs), even though that answer is in the context of domain-driven design.

Document DB Persistence

To store these objects in a document-oriented DB, you have basically two choices:

  • Store them as separate documents and reference one from the other
  • Store comments as part of their post on the post document

Both are valid approaches, you have to decide for your application. Note however that document boundaries are also consistency boundaries, so if you need atomic operations on a post and its comments, your only option is to put them on the same document.

Community
  • 1
  • 1
theDmi
  • 17,546
  • 6
  • 71
  • 138
  • Thank you for your comment. I didn't understand what you mean by my objects not being domain objects, can you explain? – areller Aug 31 '15 at 09:11
0

Absolutely you should include it. What if you want to get a list of comments but don't want to get the Post object with each comment, yet still need the PostID?

MobileMon
  • 8,341
  • 5
  • 56
  • 75