Putting additional attributes complicates db mapping, but simplifies control layer. I prefer to have pure OO in my control layer and let db layer to deal with the tables and mappings.

Putting additional attributes complicates db mapping, but simplifies control layer. I prefer to have pure OO in my control layer and let db layer to deal with the tables and mappings.

Anyway, LineItem has additional fields that do not belong on either Product or Cart. Putting that data on the Product object complicates the database mapping because it is wrong. Trying to hide the fact that LineItem is a necessary concept is a useless and complicated exercise, reflected in the fact that it is confusing and complicated (that's usually an indication you are doing something wrong.)

Anyway, LineItem has additional fields that do not belong on either Product or Cart. Putting that data on the Product object complicates the database mapping because it is wrong. Trying to hide the fact that LineItem is a necessary concept is a useless and complicated exercise, reflected in the fact that it is confusing and complicated (that’s usually an indication you are doing something wrong.)

Product, freshly inserted into ShoppingCart has one state. Product retrieved from saved has different state. Product, retrieved from order history may have state different to those two. Its up to OO persistence layer (read OR mapper) to decide whether Product stored as LineItem. But who said that ROR has proper OR mapper?

Product, freshly inserted into ShoppingCart has one state. Product retrieved from saved has different state. Product, retrieved from order history may have state different to those two. Its up to OO persistence layer (read OR mapper) to decide whether Product stored as LineItem. But who said that ROR has proper OR mapper?

Every ERP system has a line item concept for good reason. I think you spoke too soon here…

Every ERP system has a line item concept for good reason. I think you spoke too soon here…

What I was trying to say is that if it were a plain many-to-many link then this statement would be correct. In OO world that would be something like:

Order.getProducts(): List of Products

But in case of Shopping Cart it is not true. LineItem has a very specific business purpose, it stores quantity of the ordered products and the price at the moment the order was created. It might also contain some additional logic like deducting the product inventory when the order is confirmed. Note that you must keep the price in LineItem, because the product price has a tendency to change and believe me you don’t want to have an order where the sum of prices of all ordered products doesn’t match order’s subtotal.

So we have these signatures:

Order.getLineItems(): List of LineItems
LineItem.getProduct(): Product

It has nothing to do with the way you store these objects in the database, this is the domain model of any Shopping Cart application.

>Look at that from another perspective. You have shopping cart. You have products on the shelves.
>You take products and put them into shopping cart. Does behavior of the objects change once you
>put them into cart? In real world, which is Object Oriented world – product behavior is not
>changed. When why it needs to change in your computer implementation? The only way it has to
>change behavior is because relational database has no way to store objects and their state.

I don’t understand your point here. We are looking at the class diagram here which has nothing to do with objects’ behavior, but only with their relationships.

>But what if you have a way to store state and object relationships? Would you still express your
>state in relational terms?

>What I am trying to say is that objects are not 1-to-1 representation of the database and when
>you trying to create 1-to-1 you are probably doing something twice. And doing something twice
>is not good at all.

The only case where this is not 1-to-1 representation is with pure many-to-many relationships (with no additional attributes), but I don’t think it applies to this particular case. Do you know of any other cases?

What I was trying to say is that if it were a plain many-to-many link then this statement would be correct. In OO world that would be something like:

Order.getProducts(): List of Products

But in case of Shopping Cart it is not true. LineItem has a very specific business purpose, it stores quantity of the ordered products and the price at the moment the order was created. It might also contain some additional logic like deducting the product inventory when the order is confirmed. Note that you must keep the price in LineItem, because the product price has a tendency to change and believe me you don't want to have an order where the sum of prices of all ordered products doesn't match order's subtotal.

So we have these signatures:

Order.getLineItems(): List of LineItems
LineItem.getProduct(): Product

It has nothing to do with the way you store these objects in the database, this is the domain model of any Shopping Cart application.

>Look at that from another perspective. You have shopping cart. You have products on the shelves.
>You take products and put them into shopping cart. Does behavior of the objects change once you
>put them into cart? In real world, which is Object Oriented world – product behavior is not
>changed. When why it needs to change in your computer implementation? The only way it has to
>change behavior is because relational database has no way to store objects and their state.

I don't understand your point here. We are looking at the class diagram here which has nothing to do with objects' behavior, but only with their relationships.

>But what if you have a way to store state and object relationships? Would you still express your
>state in relational terms?

>What I am trying to say is that objects are not 1-to-1 representation of the database and when
>you trying to create 1-to-1 you are probably doing something twice. And doing something twice
>is not good at all.

The only case where this is not 1-to-1 representation is with pure many-to-many relationships (with no additional attributes), but I don't think it applies to this particular case. Do you know of any other cases?