He wasn't asking what his options were. He was asking what
the best method would be. Quite a different question, and
certainly not answerable at this point of the design.
Abigail | [reply] |
Abigail, I see your point. I guess mine is if he has a requirement to serialize to flat text why the heck would he not want to look at his options, the limitations of different methods, the complexity of the store -- how it effects all of the objects before he implements everything? Depending on how he implements his options for serialization become very open or very convoluted. If you need 1, take a heavy brick with you and 2, cross a road -- it makes no sense to decide how to cross the road (ignoring the core of bringing the heavy brick with you) cross the road then look back at the heavy brick on the other side wondering how you are going to get it to you. dealing with the storable issues as he decides how to implemnt his objects will save work and make for a more elegant solution.
-Waswas
| [reply] |
Yes, it's certainly possible to let have a dependency on the
storage method in your design. I won't say this is bad, but
it's not how I would do it. I would do the design of the backbone first, and have it not tainted with storage method.
The problem with that is that it's harder to switch to a
different storage method (and I don't mean switching from
YAML to Data::Dumper, but switching from flat files to DB files, or somekind of database), because the storage method
is too much wired in. If the storage method is an 'add-on',
it's easier to replace.
As for this particular problem, several methods have already
been mentioned. Writing down a comparison between all the methods would take too much of my time - the OP can do some
work as well, and download the various modules and read the
documentation.
But you are free to write an article, comparing the various
storage modules, and how they are more or less useful in
the project the OP is undertaking.... ;-)
Abigail
| [reply] |