On Aug 31, 2007, at 6:31 AM, Jus wrote:
Quite straightforward, right? I want to use value objects - but I have
some questions about how they should be used:
1) Can or should a VO contain references to or collections of other
VOs? For example, a wine has a producer. I have a wineVO and a
producerVO. Should I do something like wineVO.producerVO.name =
"Producer Name".
Take all of this with a grain of salt – others may comment on what
they believe are best practices.
I don't think there's a problem with what you are describing. A value
object can most definitely contain value objects of it's own. There's
no best practice here in my opinion. It's whatever works for you and
how granular you want to make your data.
That said, if your producer just a name can you just stuff it into a
property of the WineVO.
Still, it seems as though your application consists of just two value
objects (to make it easy for you to do and easy to manage - for now),
a WineVO and SubmissionVO. You could take the top down approach,
CountryVO -> ProducerVO -> WineVO, but that's not the focus of your
application. The focus is on the product, the important data is the
wine itself.
2) Should I transfer the entire submission (a submission is made up of
several wine entries aka WineVOs) to Flex in one big VO, then let the
user manipulate the submission VO (by adding, modifying entries) and
then save it back to the server? Is that good practice?
If the submission is literally just an Array or ArrayCollection of
value objects, then you probably don't need a separate VO for it.
If it contains additional information, then it might be a good idea
to extend a SubmissionVO as an ArrayCollection with those additional
properties you need. Helpful if it needs to be bound to some
dataProvider in your application.
Should my WineVO contain a CountryVO or just the ID of the
production country? What's the best way to get the combo box to
bind to the selected country in the WineVO but having the
dataprovider pointing to model.CountriesVO?
At the very minimum your WineVO should have a comparable property of
the country - either by name or by id, whatever you decide to choose.
You bind to the list of countries and at creationComplete for your
view just set the selected item of the combo box to the name of the
country in the WineVO. You could have a utility method that gets the
country name based on id, but it's probably just easier to match name
to name between the CountryVO.name and WineVO.country.
Your "submission edit" view would contain a local copy of the
selected WineVO and you modify a temporary instance of a WineVO right
then and there. I prefer to do any type of temporary modification to
value objects within the view. If it's complex, the view itself may
have it's own model, etc. Like a form, the data is all temporary
until you commit it. The data may come in as pre-configured, but
there's usually no use case to save each change. You can just kill
the view without any necessary cleanup.
Say you've got your submission edit dialog....
[Bindable]
private var model : WineAppModelLocator =
WineAppModelLocator.getInstance();
private var wine : WineVO;
// creationComplete...
private function init():void
{
wine = model.selectedWine;
// set combo box selected item to wine.country
// do whatever else
}
Sorry for the long post - I've reviewed a lot of the Cairngorm
examples, but they tend to deal with simple problems (like adding a
contact) and I'm finding it hard to build something a little more
complicated on top of their foundations.
I actually think your example is equal from a complexity standpoint.
There don't seem to be many user gestures here - maybe 3 or 4 I'm
guessing from the start? The hardest part is how you want to
structure your data.
good luck with it. hope something here was helpful for you.
best,
jon
