Tony Marston

Cobol programmers are a goldmine of wisdom and knowledge. You will learn more about business software from an old, unsung bloke like Tony Marston than anybody celebrated methodology or blogsphere celebrity. http://www.tonymarston.net/ Having said that. I really wish more people would ignore them, for my own competitive benefit.

[from http://www.tonymarston.net/aboutme/thoughts.html] There are two basic approaches to software development: Rules oriented - where you follow a set of rules or a methodology religiously, to the letter and without question and just assume that the results, whatever they are, must be acceptable. Results oriented - where you aim to produce the best results in the shortest possible time and use whatever methodology or rule set that helps you achieve this aim. One requires blind obedience, plus, from what I have seen on more than one occasion, an unerring ability to invent interpretations of those rules that are so obscure and perverse that they do nothing but increase complexity and decrease productivity. The other requires intelligence and skill, the ability to know which rules and methods to adopt, when and how to adapt them to fit a particular purpose, and when to reject them in favour of something better. - Tony Marston

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…