Undestanding CRUD with Composition

Question

I pretty want to understand how to organize my code. Let's say i have this class called "Brand" which has a "Product" object:

public class Brand {
   public int ID { get; set; }
   public int name { get; set; }
   public Product product { get; set; }

    public void add(Brand brand)
    {
       // Database logic
    }

}

And this class called product

public class Product {
   public int ID { get; set; }
   public int name { get; set; }
}

What i want to know is should i have a method AddProduct inside product class or should the method be on the top class "Brand". That is my confusion.

Answer 1

In order to make better sense of this, think about separation of concerns and single responsiblity. The answer in this post is a nice way of putting this.

Right now you have an object called Brand that contains a method Add and some properties related to being a Brand object. This means that not only is the Brand charged with managing itself, it's also charged with managing it's own interaction with the database. You are fixing to have a similar coupling between the Product and the database as well. Then what happens when you have a collection of brands, and you realize each brand should have a collection of products, and they all have Database logic strewn throughout? Then, say you notice that each Product needs a list of ingredients, so you have to add that, so the ingredients need database logic, etc. etc. You can see this gets very confusing very quickly.

So really, you should have a third class that is responsible for managing database objects, and that class will have methods to call that take your Brand and Product objects as parameters and interact with the database internally. Now you have abstracted your database logic away from your Brand and Product logic, so the Database class can do what it's built for and no more, and the Brand and Class objects can exist as defined wrappers for related data and no more. Everything is now divided so each class represents a single simple concept. Brand class exists to represent brand data. Database class exists to interact with the database.

I'm sure you get the concept and you may have seen this a thousand times already, but thinking like this will help you spot what needs to change and find much simpler, cleaner, more maintainable solutions.