5 ms·

The 3 tier architecture was a reaction to VB and RAD-like tools, where things like data validation and database I/O were coupled directly to the input component

The 3 tier architecture was a reaction to VB and RAD-like tools, where things like data validation and database I/O were coupled directly to the input component. It was common for these frameworks to not even have an object for data transfer sitting between UI and DB. This was the timeframe where more and more manual work was automated. Hence it was a common situation where input used to be given by a human, but now comes from another application. The simplest way to do that kind of retrofit was to drive the UI from the application: The application fills in its own gui fields which triggers the validation, then simulates a click on OK. This caused al kinds of ungodly messes. You need a gui for background processes, reliability was low, etc.. 3 tier architecture were a way to say 'never again' to this style of programming. Forcing people in to it was necessary. But that was another time. Mindlessly applying an architecture without understanding why is of course dumb. But not applying an architecture without understanding it's pros and contras is just as dumb. It all depends on the quality of the architects in question. Not that I want to call you dumb, of course. IT today is different from 20 years ago.

specialist 7y ago
n-tiered architectures were born during the transition from "workgroup" to "client/server". This upheaval caused an industry-wide loss of programming lore. It wouldn't have been too bad, except the ODBC interface inadvertently led to abandoning schema-aware programming models like VB's ADO, Paradox, FoxPro, etc. At the same time, object oriented became fashionable. So we ended up with ORMs, ActiveRecord, and various offshoots. Mostly because no one remembers life before client/server.
- aprdm 7y ago
  Can you talk more about workgroup?
  - ratww 7y ago
    Not the GP, but I used to work in desktop development for enterprise businesses. Most multi-user apps were two tiered: client and database. The way they worked was by connecting directly to the database and/or a shared filesystem in the local network. All validation happened client-side. Database credentials and fine-grained file/directory permissions were the only security measures. That and the NAT. ;) There's still software in the market that uses this model, like some niche ERPs from the 90s and software catered to small/mid businesses.
    - johnchristopher 7y ago
      > Database credentials and fine-grained file/directory permissions were the only security measures. That and the NAT. ;) It baffles me that the CCNA materials is still based around these use cases.
- hyperman1 7y ago
  I assume that's the windows 3.11 era? It was a simpler time, with small non-hostile networks, less critical software, and more humans in the loop. While 'workgroup' mostly means PC/DOS to me, the mainframes of the day had a comparable story unfolding.
  - ratww 7y ago
    Funny thing, I remember lot of similar apps in enterprise businesses until the late 2000s. That only started to change when web apps and cloud-hosted software became the norm.
- pjc50 7y ago
  I was always a bit hazy on what these terms actually meant, and what we lost. It does seem like there was a brief golden age of easy "rapid application development" tools like FoxPro where you could wire some UI fields to a database without too much trouble. Now we have people trying to do the same in the web, badly.
  - specialist 7y ago
    I also had no idea what client/server meant (at the time). My current oversimplified distinction: Workgroup: I/O thru file system, clients responsible for locking, concurrency, etc. Client/Server: I/O thru DB's protocol (eg TDS), server responsible for locking, concurrency, etc. -- As for what was lost, I spent way too long (10+ years) trying to figure that out, trying to fulfill the desire to recover the ADO (Access Data Objects) programming paradigm. I think I succeeded, more or less, and am currently reorienting my life to work on it full-time.
  - ksec 7y ago
    I used to loathe FoxPro, now I actually miss it, it was simple enough to quickly get the job done. I have always thought in the 2000s that something better, more powerful and even easier to use would come. And looking back I felt a lot of times technologies general we reinvent the wheel and nothing better actually came out of it. FileMaker may be an alternative, but I never understood why it hasn't caught on. And I am not even sure if there are any product similar that is good on the Web.
wayoutthere 7y ago
> The simplest way to do that kind of retrofit was to drive the UI from the application: The application fills in its own gui fields which triggers the validation, then simulates a click on OK. > Not that I want to call you dumb, of course. IT today is different from 20 years ago. The meteoric rise of RPA within IT shops is recreating the same situation. The more things change, the more they stay the same.
- walterbell 7y ago
  What is RPA?
  - dandelo53 7y ago
    This link should resist time rot: https://www.google.com/search?q=top+rpa+vendors https://www.google.com/search?q=top+rpa+vendors
    - walterbell 7y ago
      "Robotic process automation" was indeed what came up in my web search for the term, but it seemed an unlikely fit for generic distributed app development. Why is robotic process automation sweeping "IT shops"?
      - wayoutthere 7y ago
        Because rather than upgrading software and building APIs that integrate at a low level, IT shops are building software and APIs on top of UI automations. Some new fancy service desk platform the suits want may not have a connector to your 15 year old heavily-customized SAP instance (which is run by another team you have no influence with), and budget / time constraints leave RPA as the only option. It's pretty easy to see why this would cause problems, but the consulting companies have been pushing hard on RPA because when it blows up in 5 years, who are you going to call? I say this as a consultant who has to sell this awful crap because "partnerships".
m463 7y ago
Is MVC a good thing?

specialist 7y ago

n-tiered architectures were born during the transition from "workgroup" to "client/server". This upheaval caused an industry-wide loss of programming lore. It wouldn't have been too bad, except the ODBC interface inadvertently led to abandoning schema-aware programming models like VB's ADO, Paradox, FoxPro, etc. At the same time, object oriented became fashionable. So we ended up with ORMs, ActiveRecord, and various offshoots. Mostly because no one remembers life before client/server.

aprdm 7y ago
Can you talk more about workgroup?
- ratww 7y ago
  Not the GP, but I used to work in desktop development for enterprise businesses. Most multi-user apps were two tiered: client and database. The way they worked was by connecting directly to the database and/or a shared filesystem in the local network. All validation happened client-side. Database credentials and fine-grained file/directory permissions were the only security measures. That and the NAT. ;) There's still software in the market that uses this model, like some niche ERPs from the 90s and software catered to small/mid businesses.
  - johnchristopher 7y ago
    > Database credentials and fine-grained file/directory permissions were the only security measures. That and the NAT. ;) It baffles me that the CCNA materials is still based around these use cases.
hyperman1 7y ago
I assume that's the windows 3.11 era? It was a simpler time, with small non-hostile networks, less critical software, and more humans in the loop. While 'workgroup' mostly means PC/DOS to me, the mainframes of the day had a comparable story unfolding.
- ratww 7y ago
  Funny thing, I remember lot of similar apps in enterprise businesses until the late 2000s. That only started to change when web apps and cloud-hosted software became the norm.
pjc50 7y ago
I was always a bit hazy on what these terms actually meant, and what we lost. It does seem like there was a brief golden age of easy "rapid application development" tools like FoxPro where you could wire some UI fields to a database without too much trouble. Now we have people trying to do the same in the web, badly.
- specialist 7y ago
  I also had no idea what client/server meant (at the time). My current oversimplified distinction: Workgroup: I/O thru file system, clients responsible for locking, concurrency, etc. Client/Server: I/O thru DB's protocol (eg TDS), server responsible for locking, concurrency, etc. -- As for what was lost, I spent way too long (10+ years) trying to figure that out, trying to fulfill the desire to recover the ADO (Access Data Objects) programming paradigm. I think I succeeded, more or less, and am currently reorienting my life to work on it full-time.
- ksec 7y ago
  I used to loathe FoxPro, now I actually miss it, it was simple enough to quickly get the job done. I have always thought in the 2000s that something better, more powerful and even easier to use would come. And looking back I felt a lot of times technologies general we reinvent the wheel and nothing better actually came out of it. FileMaker may be an alternative, but I never understood why it hasn't caught on. And I am not even sure if there are any product similar that is good on the Web.

wayoutthere 7y ago

> The simplest way to do that kind of retrofit was to drive the UI from the application: The application fills in its own gui fields which triggers the validation, then simulates a click on OK. > Not that I want to call you dumb, of course. IT today is different from 20 years ago. The meteoric rise of RPA within IT shops is recreating the same situation. The more things change, the more they stay the same.

walterbell 7y ago
What is RPA?
- dandelo53 7y ago
  This link should resist time rot: https://www.google.com/search?q=top+rpa+vendors https://www.google.com/search?q=top+rpa+vendors
  - walterbell 7y ago
    "Robotic process automation" was indeed what came up in my web search for the term, but it seemed an unlikely fit for generic distributed app development. Why is robotic process automation sweeping "IT shops"?
    - wayoutthere 7y ago
      Because rather than upgrading software and building APIs that integrate at a low level, IT shops are building software and APIs on top of UI automations. Some new fancy service desk platform the suits want may not have a connector to your 15 year old heavily-customized SAP instance (which is run by another team you have no influence with), and budget / time constraints leave RPA as the only option. It's pretty easy to see why this would cause problems, but the consulting companies have been pushing hard on RPA because when it blows up in 5 years, who are you going to call? I say this as a consultant who has to sell this awful crap because "partnerships".

m463 7y ago

Is MVC a good thing?