locked
Class / Data Design Question RRS feed

  • Question

  • User490419145 posted

    Hello Everyone,

    My question revolved around proper object oriented design.  Right now, we use a lot of web forms and no entity framework.

    Let's say, as an example, I have 4 SQL database tables.  

    • One called "products" where we store all products we can sell
      • productID (int), name(nvarchar), price(float).
         
    • One called "clients" where we store all our clients
      • clientID (int), name (nvarchar)
         
    • One called "orders" where we store all customers
      • orderID (int), clientID(int), and dateCreated (datetime).
         
    • One called "orders_products_REL" where we store the relationship between products, and orders.  We can override a products cost, to give it an increase or decrease of price.
      • relID(int), orderID(int), productID(int), price (float)

    So in my C#, I make 3 classes, one called "products", "clients", and "orders" all in their own .cs files.  Within these classes I just define the object as I did in SQL.  

    Usually, I'll make a seperate "controller/manager" class for each object, that handles CRUD operations for the objects.

    My question is this.

    1. Would it be better to store the "orders" class/objects within a client class/object?  Since I can never have an order without a clientID would it make more sense, and be more "proper" to say Client.Orders.Create() or just Orders.Create() as I do now?

    2. What is the best way to handle a one-to-many relationship like my table "products_orders_REL"?  Do I make a class/object specifically for that?  What woulkd you call the class/object?  Where would you nest it?

    Thoughts?  Opinions?

    Tuesday, November 6, 2012 1:14 PM

Answers

  • User-821857111 posted

    Would it be better to store the "orders" class/objects within a client class/object?  Since I can never have an order without a clientID would it make more sense, and be more "proper" to say Client.Orders.Create() or just Orders.Create() as I do now?

    Orders do not place or create themselves, so if you want to apply behaviour anywhere, mirror the real world. In the real world, a customer places an order:

    Client.Place(Order order)

    What is the best way to handle a one-to-many relationship like my table "products_orders_REL"?  Do I make a class/object specifically for that?  What woulkd you call the class/object?  Where would you nest it?

    If you mirror the real world, your object model should have a client object that has a collection of order objects, each of which has a collection of order items. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 6, 2012 3:04 PM

All replies

  • User-821857111 posted

    Would it be better to store the "orders" class/objects within a client class/object?  Since I can never have an order without a clientID would it make more sense, and be more "proper" to say Client.Orders.Create() or just Orders.Create() as I do now?

    Orders do not place or create themselves, so if you want to apply behaviour anywhere, mirror the real world. In the real world, a customer places an order:

    Client.Place(Order order)

    What is the best way to handle a one-to-many relationship like my table "products_orders_REL"?  Do I make a class/object specifically for that?  What woulkd you call the class/object?  Where would you nest it?

    If you mirror the real world, your object model should have a client object that has a collection of order objects, each of which has a collection of order items. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, November 6, 2012 3:04 PM
  • User303909271 posted

    Hi,

    For your questions:

    1.

    Would it be better to store the "orders" class/objects within a client class/object?  Since I can never have an order without a clientID would it make more sense, and be more "proper" to say Client.Orders.Create() or just Orders.Create() as I do now?

    The method should be "Orders Client.Orders()". It is not necessary to have Create(). "Orders.Create()" will represent all orders, not specific to any particular client. The meaning is different.

    2. 

    What is the best way to handle a one-to-many relationship like my table "products_orders_REL"?  Do I make a class/object specifically for that?  What woulkd you call the class/object?  Where would you nest it?

    Createing a class/object specifically for that is NOT a good idea. In your case, the design should be "OrderInfo Order.GetOrderInfo()". The OrderInfo class has the information of Product and Price.

    Hope that helps.

    Kevin Gao

    MCSD, MCDBA, MBA 

    Friday, November 9, 2012 2:55 AM