xiaoyafeng has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks!

I'd like to create a persistent class between application library and data. But what stick to me now is where the data store is variant, including database, files and remote DCOM server. So my question is:

should I write *one* general persistent class for all three or write 3 class to correspond to 3 diffent types of data.

second, is there a mature,easy-to-use framework in cpan for the usage like this? I've just searched for it , but persistent looks like stalled since 2000.

BTW the framework meet my need is simple I think: Thanks!


I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Replies are listed 'Best First'.
Re: persistent object framework
by dsheroh (Monsignor) on Mar 02, 2013 at 10:10 UTC
    should I write *one* general persistent class for all three or write 3 class to correspond to 3 diffent types of data.
    Both.

    The best approach would be to write one general persistent class which defines the interface to your persistence mechanisms and then create plugins which it uses to communicate with each actual back-end data store. (This is the same model used by DBI, where DBI itself is the "general class" and the various DBD drivers are the "plugins".)

    Another approach would be to derive subclasses for each back-end, but the DBI-style approach tends to be more flexible and provides a better interface for allowing users to configure how/where they want their data stored.

[reply]
Re: persistent object framework
by Anonymous Monk on Mar 01, 2013 at 23:22 UTC
[reply]

Back to Seekers of Perl Wisdom