Object hierarchy

Object hierarchy

Old forum URL: forums.lhotka.net/forums/t/7983.aspx


krasimir posted on Thursday, November 12, 2009

Hello,

I look through many of the discussions here about switchable objects, but I still didn't find the solution for my problem. Right now I'm reading the 2008 edition of the book, and several years ago I read the 2005 edition, and I build one project with CSLA 2.7 two years ago.
Still, the concept of Parent and Child objects is probably the most confusing part to me.

My case is like this:
I should build a ShoppingCart object, which will have Products collection with many Product object. Each Product will contain other business objects as properties, but this is not what concerns me.

What I'm still didn't quite get, is how to implement the Product object?
On one hand, it is part of a ShoppingCart, and as such it should be declared as child object - probably the parent will be a Products collection which will be the child of the ShoppingCart object.

On the other hand, when I'm adding new product to the system, it is not part of any ShoppingCart yet and it is definitely a parent object! Only after the Product is added in the system, it eventually can became part of some ShoppingCart object, but this is not a requirement, but only a possibility.

So, after read all the answers here, I get to the point when as I see it, I have two options:
  1. Implement Product as switchable object, in order to satisfy my two use cases, or
  2. Define two different objects which will probably have different sets of properties - one object which will represent the Product when it is part of some ShoppingCart object, and probably in this case the Product will have a limited set of properties - only these that are displayed to the user when he sees the ShoppingCart.
    The second object will represent the Product when a new Product is added to the system and it will contain full set of properties.
Am I getting it right, or am I completely wrong?

I will highly appreciate any comments on that!

Thanks,
Krasimir Evtimov

P.S. If something is not clear, please let me know so I can explain it.

chrduf replied on Thursday, November 12, 2009

Hi

 

In this case I would define 2 separate objects for the 2 scenarios. Your business and validation logic will likely be different and the objects will be less complex than trying to do this as one object.

 

 

From: krasimir [mailto:cslanet@lhotka.net]
Sent: Thursday, November 12, 2009 11:30 AM
To: chris.dufour@wigets.net
Subject: [CSLA .NET] Object hierarchy

 

Hello,

I look through many of the discussions here about switchable objects, but I still didn't find the solution for my problem. Right now I'm reading the 2008 edition of the book, and several years ago I read the 2005 edition, and I build one project with CSLA 2.7 two years ago.
Still, the concept of Parent and Child objects is probably the most confusing part to me.

My case is like this:
I should build a ShoppingCart object, which will have Products collection with many Product object. Each Product will contain other business objects as properties, but this is not what concerns me.

What I'm still didn't quite get, is how to implement the Product object?
On one hand, it is part of a ShoppingCart, and as such it should be declared as child object - probably the parent will be a Products collection which will be the child of the ShoppingCart object.

On the other hand, when I'm adding new product to the system, it is not part of any ShoppingCart yet and it is definitely a parent object! Only after the Product is added in the system, it eventually can became part of some ShoppingCart object, but this is not a requirement, but only a possibility.

So, after read all the answers here, I get to the point when as I see it, I have two options:

  1. Implement Product as switchable object, in order to satisfy my two use cases, or
  2. Define two different objects which will probably have different sets of properties - one object which will represent the Product when it is part of some ShoppingCart object, and probably in this case the Product will have a limited set of properties - only these that are displayed to the user when he sees the ShoppingCart.
    The second object will represent the Product when a new Product is added to the system and it will contain full set of properties.

Am I getting it right, or am I completely wrong?

I will highly appreciate any comments on that!

Thanks,
Krasimir Evtimov

P.S. If something is not clear, p lease let me know so I can explain it.


skagen00 replied on Thursday, November 12, 2009

Is product basically a leather wallet, a CSLA t-shirt, or a Swingline stapler, and you're wondering how to reuse this for shopping cart purposes?

Don't!

You might have:
Product - an editable root for actually configuring products available.

ProductInfo - a read-only info object to get qualities about a product the user might order - you might bring in, for example, how many are left - etc.

ShoppingCart - an editable root representing a user's shopping cart

ShoppingCartItemCollection - a child of ShoppingCart and collection containing ShoppingCartItems.

ShoppingCartItem - a child object, with a ProductId, some basic read-only information about a product if it's useful in your use case to display the shopping cart, quantity of item in the cart, etc.

Obviously everything depends on your use cases, but I'd echo using multiple objects. Reuse is not the goal.

krasimir replied on Monday, November 16, 2009

Thank you very much to both of you!

So you both suggest me to go with two different objects. I will try to see how the things will go and will report back when I have something to share.

Meanwhile, if anyone has a different point of view - please share!

Thanks again

Copyright (c) Marimer LLC