3 added 1 character in body
source | link

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makescauses problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, because you expect client code which can make use of both methods in a meaningful way, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

This gives the user of your system a little bit more "syntactic sugar" without adding too much additional code.

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, because you expect client code which can make use of both methods in a meaningful way, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

This gives the user of your system a little bit more "syntactic sugar" without adding too much additional code.

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that causes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, because you expect client code which can make use of both methods in a meaningful way, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

This gives the user of your system a little bit more "syntactic sugar" without adding too much additional code.

2 added 201 characters in body
source | link

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, because you expect client code which can make use of both methods in a meaningful way, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

This gives the user of your system a little bit more "syntactic sugar" without adding too much additional code.

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, because you expect client code which can make use of both methods in a meaningful way, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }

This gives the user of your system a little bit more "syntactic sugar" without adding too much additional code.

1
source | link

(I guess GetProductsInThisCategory is not intended to be a repo method, but a category method, correct me if I am wrong).

Both is possible, and even a solution where you have both at the same time. A Product will probably know its category, so GetProductsByCategory(CategoryId) will often make sense, as Product already depends on Category. Introducing a Category method GetProductsInThisCategory() will imply that Category also depends on Product, so it leads to a cyclic dependency (which is often acceptable, not necessarily a bad solution, but if that makes problems in your environment or overall architecture, avoid it).

Assumed the cyclic dependency is not a problem, I recommend to implement the method or methods which lead to the shorter code at the components which use that methods. If you are going to implement both, implement one in terms of the other method to avoid duplicated logic, for example:

 GetProductsInThisCategory()
 {
     return prodRepo.GetProductsByCategory(this.ID);
 }