Design pattern for nested many-to-many relationships in EF Core











up vote
0
down vote

favorite












I have designed the domain models for my ASP.NET Core server side application with join tables to create many-to-many relationships. I am unsure if the design is sound and I am trying to understand if there are common design patterns for my model. I am inexperienced in designing models. I have included an abstraction of my models below.



My business rules are: an Owner can own many PencilCase. PencilCase is in the theme of ColorsInCase and a Color can only exist once in the PencilCase, but the PencilCase can have a collection of Pen (in different Size) in that Color and a collection of Pencil in that Color (again in different Size). The PencilCase should not hold two Pen of the same Size in the same Color (same for Pencil).



An example of where I am doubtful for my design: ColorInCase has its own Id while it could be a composite of PencilCaseId and ColorId. But then I am not sure how I can reference ColorInCase in Pen and Pencil if it doesn't have its own Id.



Another example of my concern: my principal object is actually the Owner, but in this design I would start from PencilCase to get a relationship with Owner. I am not sure if this will get me in difficulty later on.



Is this a sound model design, or is there a common design pattern for these nested many-to-many relationships (or nested collections)?



public class Owner
{
public int Id { get; set; }
public string Name { get; set; }
}
public class PencilCase
{
public int Id { get; set; }
public int OwnerId { get; set; }
public Owner Owner { get; set; }
public List<ColorInCase> ColorsInCase { get; set; }
public PencilCase()
{
ColorsInCase = new List<ColorInCase>();
}

}
public class Color
{
public int Id { get; set; }
public string Name { get; set; }
}
public class ColorInCase
{
public int Id { get; set; }
public int PencilCaseId { get; set; }
public PencilCase PencilCase { get; set; }
public int ColorId { get; set; }
public Color Color { get; set; }
public List<Pencil> Pencils { get; set; }
public List<Pen> Pens { get; set; }
public ColorInCase()
{
Pencils = new List<Pencil>();
Pens = new List<Pen>();
}
}

public class Pen
{
public byte Size { get; set; }
public int ColorInCaseId { get; set; }
public ColorInCase ColorInCase { get; set; }

}

public class Pencil
{
public byte Size { get; set; }
public int ColorInCaseId { get; set; }
public ColorInCase ColorInCase { get; set; }
}


Pen and Pencil have a key created by ModelBuilder on Size and









share







New contributor




Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
























    up vote
    0
    down vote

    favorite












    I have designed the domain models for my ASP.NET Core server side application with join tables to create many-to-many relationships. I am unsure if the design is sound and I am trying to understand if there are common design patterns for my model. I am inexperienced in designing models. I have included an abstraction of my models below.



    My business rules are: an Owner can own many PencilCase. PencilCase is in the theme of ColorsInCase and a Color can only exist once in the PencilCase, but the PencilCase can have a collection of Pen (in different Size) in that Color and a collection of Pencil in that Color (again in different Size). The PencilCase should not hold two Pen of the same Size in the same Color (same for Pencil).



    An example of where I am doubtful for my design: ColorInCase has its own Id while it could be a composite of PencilCaseId and ColorId. But then I am not sure how I can reference ColorInCase in Pen and Pencil if it doesn't have its own Id.



    Another example of my concern: my principal object is actually the Owner, but in this design I would start from PencilCase to get a relationship with Owner. I am not sure if this will get me in difficulty later on.



    Is this a sound model design, or is there a common design pattern for these nested many-to-many relationships (or nested collections)?



    public class Owner
    {
    public int Id { get; set; }
    public string Name { get; set; }
    }
    public class PencilCase
    {
    public int Id { get; set; }
    public int OwnerId { get; set; }
    public Owner Owner { get; set; }
    public List<ColorInCase> ColorsInCase { get; set; }
    public PencilCase()
    {
    ColorsInCase = new List<ColorInCase>();
    }

    }
    public class Color
    {
    public int Id { get; set; }
    public string Name { get; set; }
    }
    public class ColorInCase
    {
    public int Id { get; set; }
    public int PencilCaseId { get; set; }
    public PencilCase PencilCase { get; set; }
    public int ColorId { get; set; }
    public Color Color { get; set; }
    public List<Pencil> Pencils { get; set; }
    public List<Pen> Pens { get; set; }
    public ColorInCase()
    {
    Pencils = new List<Pencil>();
    Pens = new List<Pen>();
    }
    }

    public class Pen
    {
    public byte Size { get; set; }
    public int ColorInCaseId { get; set; }
    public ColorInCase ColorInCase { get; set; }

    }

    public class Pencil
    {
    public byte Size { get; set; }
    public int ColorInCaseId { get; set; }
    public ColorInCase ColorInCase { get; set; }
    }


    Pen and Pencil have a key created by ModelBuilder on Size and









    share







    New contributor




    Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I have designed the domain models for my ASP.NET Core server side application with join tables to create many-to-many relationships. I am unsure if the design is sound and I am trying to understand if there are common design patterns for my model. I am inexperienced in designing models. I have included an abstraction of my models below.



      My business rules are: an Owner can own many PencilCase. PencilCase is in the theme of ColorsInCase and a Color can only exist once in the PencilCase, but the PencilCase can have a collection of Pen (in different Size) in that Color and a collection of Pencil in that Color (again in different Size). The PencilCase should not hold two Pen of the same Size in the same Color (same for Pencil).



      An example of where I am doubtful for my design: ColorInCase has its own Id while it could be a composite of PencilCaseId and ColorId. But then I am not sure how I can reference ColorInCase in Pen and Pencil if it doesn't have its own Id.



      Another example of my concern: my principal object is actually the Owner, but in this design I would start from PencilCase to get a relationship with Owner. I am not sure if this will get me in difficulty later on.



      Is this a sound model design, or is there a common design pattern for these nested many-to-many relationships (or nested collections)?



      public class Owner
      {
      public int Id { get; set; }
      public string Name { get; set; }
      }
      public class PencilCase
      {
      public int Id { get; set; }
      public int OwnerId { get; set; }
      public Owner Owner { get; set; }
      public List<ColorInCase> ColorsInCase { get; set; }
      public PencilCase()
      {
      ColorsInCase = new List<ColorInCase>();
      }

      }
      public class Color
      {
      public int Id { get; set; }
      public string Name { get; set; }
      }
      public class ColorInCase
      {
      public int Id { get; set; }
      public int PencilCaseId { get; set; }
      public PencilCase PencilCase { get; set; }
      public int ColorId { get; set; }
      public Color Color { get; set; }
      public List<Pencil> Pencils { get; set; }
      public List<Pen> Pens { get; set; }
      public ColorInCase()
      {
      Pencils = new List<Pencil>();
      Pens = new List<Pen>();
      }
      }

      public class Pen
      {
      public byte Size { get; set; }
      public int ColorInCaseId { get; set; }
      public ColorInCase ColorInCase { get; set; }

      }

      public class Pencil
      {
      public byte Size { get; set; }
      public int ColorInCaseId { get; set; }
      public ColorInCase ColorInCase { get; set; }
      }


      Pen and Pencil have a key created by ModelBuilder on Size and









      share







      New contributor




      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      I have designed the domain models for my ASP.NET Core server side application with join tables to create many-to-many relationships. I am unsure if the design is sound and I am trying to understand if there are common design patterns for my model. I am inexperienced in designing models. I have included an abstraction of my models below.



      My business rules are: an Owner can own many PencilCase. PencilCase is in the theme of ColorsInCase and a Color can only exist once in the PencilCase, but the PencilCase can have a collection of Pen (in different Size) in that Color and a collection of Pencil in that Color (again in different Size). The PencilCase should not hold two Pen of the same Size in the same Color (same for Pencil).



      An example of where I am doubtful for my design: ColorInCase has its own Id while it could be a composite of PencilCaseId and ColorId. But then I am not sure how I can reference ColorInCase in Pen and Pencil if it doesn't have its own Id.



      Another example of my concern: my principal object is actually the Owner, but in this design I would start from PencilCase to get a relationship with Owner. I am not sure if this will get me in difficulty later on.



      Is this a sound model design, or is there a common design pattern for these nested many-to-many relationships (or nested collections)?



      public class Owner
      {
      public int Id { get; set; }
      public string Name { get; set; }
      }
      public class PencilCase
      {
      public int Id { get; set; }
      public int OwnerId { get; set; }
      public Owner Owner { get; set; }
      public List<ColorInCase> ColorsInCase { get; set; }
      public PencilCase()
      {
      ColorsInCase = new List<ColorInCase>();
      }

      }
      public class Color
      {
      public int Id { get; set; }
      public string Name { get; set; }
      }
      public class ColorInCase
      {
      public int Id { get; set; }
      public int PencilCaseId { get; set; }
      public PencilCase PencilCase { get; set; }
      public int ColorId { get; set; }
      public Color Color { get; set; }
      public List<Pencil> Pencils { get; set; }
      public List<Pen> Pens { get; set; }
      public ColorInCase()
      {
      Pencils = new List<Pencil>();
      Pens = new List<Pen>();
      }
      }

      public class Pen
      {
      public byte Size { get; set; }
      public int ColorInCaseId { get; set; }
      public ColorInCase ColorInCase { get; set; }

      }

      public class Pencil
      {
      public byte Size { get; set; }
      public int ColorInCaseId { get; set; }
      public ColorInCase ColorInCase { get; set; }
      }


      Pen and Pencil have a key created by ModelBuilder on Size and







      c# asp.net-core entity-framework-core





      share







      New contributor




      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.










      share







      New contributor




      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.








      share



      share






      New contributor




      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 3 mins ago









      Superman.Lopez

      11




      11




      New contributor




      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Superman.Lopez is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.



























          active

          oldest

          votes











          Your Answer





          StackExchange.ifUsing("editor", function () {
          return StackExchange.using("mathjaxEditing", function () {
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          });
          });
          }, "mathjax-editing");

          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "196"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });






          Superman.Lopez is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209042%2fdesign-pattern-for-nested-many-to-many-relationships-in-ef-core%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown






























          active

          oldest

          votes













          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          Superman.Lopez is a new contributor. Be nice, and check out our Code of Conduct.










          draft saved

          draft discarded


















          Superman.Lopez is a new contributor. Be nice, and check out our Code of Conduct.













          Superman.Lopez is a new contributor. Be nice, and check out our Code of Conduct.












          Superman.Lopez is a new contributor. Be nice, and check out our Code of Conduct.
















          Thanks for contributing an answer to Code Review Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          Use MathJax to format equations. MathJax reference.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209042%2fdesign-pattern-for-nested-many-to-many-relationships-in-ef-core%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          404 Error Contact Form 7 ajax form submitting

          How to know if a Active Directory user can login interactively

          Refactoring coordinates for Minecraft Pi buildings written in Python