K, I'm going to throw my hat in the ring here and say this is a good idea, and outline (mostly through referencing other people's work as it's 00.38) how I've s

K, I'm going to throw my hat in the ring here and say this is a good idea, and outline (mostly through referencing other people's work as it's 00.38) how I've spent the last few years building applications. I'm going to intentionally simplify so that the less experienced here can keep up (hopefully). For those with more code-fu, feel free to poke me for more information. Right, imagine we have a blog engine for something that needs to be able to handle huge data requests. Our code base logic at its simplest looks something like this: Down: Request -> Router (turns URL structure into a set of useful data inputs) -> Pre-processor (uses those inputs to fire up the classes we'll need, namely to get data first) -> Primary validation (makes sure everything that was put in is sensible and safe) -> Model pre-processor (calculates which data store we need to query, a key-value store of all data, a cache of various pieces of data, or our single monolithic store) -> Data store (cache/database/whatver) Up: Model post-processor (where our data was anything other than our computer store of values, generate whatever needs to be there and store it for next time) -> Secondary validation (ensure our output is sanitized) -> Business logic post-processor (to apply any data transformation required) -> Output It's specifically the pre-processor that we're talking about here. There's millions of ways to implement it, but something like what's outlined in the original post is currently my favourite way, for both the logging/debugging options it gives, as well as the data manipulation tools that it de facto provides. Whilst some of it isn't very sensible for modern web practice (XML/XSLT for example), this by Tony Marston is well worth studying until you really grok it, as a fuller representation of what we're talking about here: http://tonymarston.net/php-mysql/infrastructure.html http://tonymarston.net/php-mysql/infrastructure.html This is essentially taking elements 3, 4, 5 & 6 and abstracting them out so that rather than just being for talking to databases as data stores, they're able to talk to a variety of other model data sources - cache levels, the database and a globally pre-computered store of all possible values (for the fastest level of access). I'm also going to re-state the shout-out made in the original post to Nathan Marz' work here: http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html. Excellent reading for anyone interested in large-scale application design. I'll also through in this excellent post on event sourcing by Martin Fowler: http://www.martinfowler.com/eaaDev/EventSourcing.html http://www.martinfowler.com/eaaDev/EventSourcing.html Questions?