Re: Newbie: Design Question
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Thu, 06 Mar 2008 17:52:53 -0800
On Thu, 06 Mar 2008 17:26:17 -0800, GiJeet <gijeet@xxxxxxxxx> wrote:
[...]
So here's the design question:
I was thinking of having an AddToStore method in the book class and an
array list of bookstores as part of each book instance. Then I call
the AddToStore method and the book will loop thru it's array of
bookstores and add itself to each bookstore, since in real life that's
what we do - we add books to bookstores.
However, then I have the same instance reference of the book at each
store right?.
Yes, if you keep reusing that same instance.
This defeats the idea of having an individual
WasNoticeSent flag on the book to indicate that a notice was sent to
the local customers for this book from a specific bookstore. That is,
if I set the flag for bookstore1 to true, then when bookstore2 goes to
check if the notice was sent for the customers of that store the flag
will indicate it was and it really wasn't. Maybe clone each book for
each store?
Or....should I loop thru the bookstores and create a separate instance
of each book for each bookstore. This seems like extra work since
most of the information for a book doesn't change for each bookstore -
same title, isbn, price, etc.
Your heart is in the right place. :) Yes, it would be wasteful to create a new instance of a class that contains non-variant information about the book for each physical book.
I haven't done any inventory control software, but from what I've seen, it seems to me that they generally maintain the stock item information separately from the inventory item information. That is, you'd have a single "stock item" that represents the archetype of the inventory item, in which is contained all of the non-variant descriptive stuff. For a book, this would those things you described: title, author, ISBN, suggested price, publisher, etc.
Then for each store, you'd have an inventory item that refers to that stock item. The inventory item would contain at a minimum two things: an in-store inventory count of the item, and a reference to the stock item instance. Depending on how the stores work, you might actually have an actual price field (if different stores are allowed to price items differently...to support a clearance sale at one store, for example).
Finally, you've said you want to handle things like notices to customers. One approach would be to skip the "in-store inventory count" I mentioned above and just create a new instance of the inventory item class for each actual book a store might receive. However, I think this would probably be wasteful, since the vast majority of books will never have any customer-specific data in them. Instead, I think it probably makes more sense to maintain a list of customers attached to each inventory item class. The customer-specific class would contain whatever details are relevant (including, if appropriate, a reference to a global customer data class)
Of course, if books can be set aside for customers, then in that inventory item class you'll probably also want to track a separate count related to the number of customers that have already been promised a book. This might be as simple as just the length of the list of customers, or depending on how the business works you might have some customers who have paid for the book or otherwise made a claim to one, while others only requested some sort of notification and thus don't represent an actual claim on a book. How to do this would depend on specifics to your data management.
The above is just one option. It's not the only one, and alternatives might be correct as well (maybe better, maybe worse). For example, you could maintain inventory globally, with a single inventory item class that keeps a list of all stores where that item is stocked and how many instances the store has. Or you could link the structures both ways, with the inventory items having a list of stores and inventory in each store, while each store has its own list of inventory items and count of items there. Or you could store the count in just one or the other; since each has a reference to the other, whichever class doesn't store the count could just refer to the class that does have the count.
There are numerous variations, and to some extent you just need to decide for yourself what works best given how the stores operate.
Finally, all of the above assumes a straight in-memory data structure describing the situation. I think in reality you're probably going to have a relational database, with tables for stores, books, inventory, customers, etc. So, as you put everything together, obviously you'll want to keep in mind how these data structures map into and out of the database.
Pete
.
- References:
- Newbie: Design Question
- From: GiJeet
- Newbie: Design Question
- Prev by Date: LINQ
- Next by Date: Re: LINQ
- Previous by thread: Newbie: Design Question
- Next by thread: Re: Newbie: Design Question
- Index(es):
Relevant Pages
|
