The application we built did not access the database per request. That was the point of the blob of data that was not serialized and deserialized; it was a disconnected data set.
IIS was used purely as a driver for an IHttpHandler implementation. We didn't use any of ASP.NET apart from implement that interface. We implemented our own AJAX component system before ASP.NET had AJAX controls.
It was fairly quick on 2003 hardware. Further, the blob of data started out with an embedded URL that referenced a private metadata server, with the version of the app included in the URL. The behaviour for the objects in the little heap was driven from code loaded (normally, cached) via that URL. This meant that you could post-mortem a session by loading up the heap almost like you load up a core dump; you could save the heap along with the request if an error occurred, and have everything you needed for a full repro.
The fact that the URL referenced the code for the behaviour also meant we could roll out updates without ever restarting anything, and existing sessions would see the old behaviour until they were finished, but new sessions would roll over immediately to the new code.
For the niche (data entry, specifically for the insurance industry), I have yet to see a better system than the one we built; it was declarative and typed, and if it compiled, you could be pretty sure it worked, and yet had a built-in API for testing. Loading up the aforementioned core dump even had a REPL. Rails is an enormous pile of work and rats nest of polyglot spaghetti by comparison.
To take a specific example, the application code had a definition for the UI for any given page, and knew what controls were on it, and knew their master / detail relationships. The controls had bindings that were evaluated in the context of the object model stored in the little heap, written in a little expression language called Gravity (so called because it sucked in other responsibilities). So when the end-user loaded up a page, the declaration of the UI and its bindings were sufficient to infer what data to send down to the client; and when e.g. a button was clicked, and the model changed, we could calculate minimal updates to send back to the client. Because the framework knew so much about the app declaratively, you had to do very little work to implement things.
Can I do what exactly? I'm not your monkey.
The application we built did not access the database per request. That was the point of the blob of data that was not serialized and deserialized; it was a disconnected data set.
IIS was used purely as a driver for an IHttpHandler implementation. We didn't use any of ASP.NET apart from implement that interface. We implemented our own AJAX component system before ASP.NET had AJAX controls.
It was fairly quick on 2003 hardware. Further, the blob of data started out with an embedded URL that referenced a private metadata server, with the version of the app included in the URL. The behaviour for the objects in the little heap was driven from code loaded (normally, cached) via that URL. This meant that you could post-mortem a session by loading up the heap almost like you load up a core dump; you could save the heap along with the request if an error occurred, and have everything you needed for a full repro.
The fact that the URL referenced the code for the behaviour also meant we could roll out updates without ever restarting anything, and existing sessions would see the old behaviour until they were finished, but new sessions would roll over immediately to the new code.
For the niche (data entry, specifically for the insurance industry), I have yet to see a better system than the one we built; it was declarative and typed, and if it compiled, you could be pretty sure it worked, and yet had a built-in API for testing. Loading up the aforementioned core dump even had a REPL. Rails is an enormous pile of work and rats nest of polyglot spaghetti by comparison.
To take a specific example, the application code had a definition for the UI for any given page, and knew what controls were on it, and knew their master / detail relationships. The controls had bindings that were evaluated in the context of the object model stored in the little heap, written in a little expression language called Gravity (so called because it sucked in other responsibilities). So when the end-user loaded up a page, the declaration of the UI and its bindings were sufficient to infer what data to send down to the client; and when e.g. a button was clicked, and the model changed, we could calculate minimal updates to send back to the client. Because the framework knew so much about the app declaratively, you had to do very little work to implement things.