Re^3: Reflections on the design of a pure-Moose web app...

[sundialsvc4]

The application is built on top of a fully normalized and very well-constructed database. (That I didn't even have to construct! It was already there!)

The advantage of the approach that I took in this application is that “almost all of the web application” did not have to be concerned with the vagaries of the structure of that database. The “Things” know how (and when...) to retrieve information from it, and to post information back to it. Having done so, they can retain the information, and make not-yet-permanent contemplated changes to it, without “hitting” the production database at all.

I posit that such an approach provides for excellent separation-of-concerns within the application, and that it strictly avoids the problem of having the software design be subtly linked-to, hence dependent upon, the schema of that production database. Unstructured information of a reasonable size (i.e. a Perl object) can be stored separately for a reasonable time, in an altogether separate data-store, and then posted to the database only when, and if, necessary. Information is retrieved only on-demand, yet only the object need be aware of when such a “demand” has actually taken place.

So... am I arguing any of your points? Absolutely not. Instead, I am just here to say:   “Hey! Looky! This approach worked really well for me!” It is a very noticeable improvement that is going to stay at the top of my tool-bag for a while.

[stvn]

To perrins point about concurrent access to the serialized JSON files, you might want to take a look at KiokuDB, the BDB backend provides full ACIDy transactional goodness and works even more transparently then MooseX::Storage does.