Design question: create dummy objects or not?

alef posted on Wednesday, February 20, 2008

I’m developing a point of sale application.

Use case:

User wants to edit an existing article (e.g. a shoe with identity 123).

This shoe has a property beam of measures e.g. men_shoes (which include for example the sizes 36, 37, 38, 39,40, 41, 42)

Now the users want to edit this article.

On the screen he wants to see:

- season

- mark

- beam of measures

- a grid with all the possible sizes on the first column and the second column the price of the article for this particular size.

Size Price

39 12

40 12

Notice: only a price is filled for the sizes 39 and 40. This means for this article the manager of the shop has only bought these two sizes (the manufacturer makes also the other sizes). But by filling in only a price for particular sizes the user knows that only these sizes are being sold in the shop.

In the database we have the following tables

Article with fields Id, Name, Season, Mark, Beam of measures, ..

ArticleDetails with fields Id, ArticleId, SizeId, Price

Sizes with fields Id, Type, Name

For database efficiency my idea is to store in the table ArticleDetails only records for the sizes we have in the shop. In our example two records for the sizes 39 and 40.

My design question is now the following.

I will create an editable root parent object for Article.

This object will have a child collection of the sizes.

Should I construct a collection with records for each size, so not only records for 39 and 40, but records for all the sizes? So is this a good object oriented design to create a child collection like this because in the database we don’t have so many records? Or is it the responsibility of the GUI to do this, see what beam of measures the article has, show on the screen all the possible sizes and put a price for the right size?

I was thinking to construct the collection that the GUI wants in the business layer. So the GUI just binds the collection Article.Sizes to a grid and the job is done.

Can you give me some advise what is a good approach?

jeff replied on Wednesday, February 20, 2008

I know someone else might have a more detailed reply but since I'm bored I'll throw out a little of my opinion.

The size/price listing looks like a read only collection that is specific to this UI. I would not have the biz objects responsible for producing this otherwise they get cluttered up with code specific to particular UIs. You could instantiate a read only collection with 1 - list of valid sizes, 2 - article details, then have it populate itself with children items specific for this UI view.

Now, since the UI grid does not line up exactly with your biz objects I think you would need to intercept grid edits and do the add/remove to the article details biz objects yourself.

Just some thoughts.

alef replied on Thursday, February 21, 2008

I think we want the GUI as "dumb" as possible so that when it comes time to build a new one we don't have to transfer a lot of logic from the old UI to the new one.

On top of that suppose you have other screens where you have to fill in quantities that you have ordered for this article, you want to see also all the possible sizes (disable the sizes that you don't sell so that the user can not order this).

So I think in a Point Of Sale application everywhere an article is showed all the possible sizes are showed. So if this is the case, shouldn't it be better to construct the business objects in the way the GUI can use it immediately?

Can you point me in the good direction of how to create a good object model?

jeff replied on Thursday, February 21, 2008

OK, so maybe you do need functional objects to represent the sizes and articles together. In my original response I was more thinking of it as just a different view of the business information. You'll just have to handle the DB mismatch in the dataportal methods. So in your update for the "PricePerSize" object you would be adding/removing article detail rows. Maybe your use cases don't require an actual article detail object even though its a table in the DB.