Most individuals would agree that a typical visit to the emergency department can be a headache — quite literally and figuratively. The depressing waiting area, cold patient rooms, stiff pillows, the overwhelming scent of bleach, the nurse’s button seemingly only working on occasion, and the uncertainty of either becoming admitted or being discharged home all contribute to the experience one encounters, usually in the early hours of the night.
Behind the scenes, the perception is a bit more chaotic: EMTs rushing stretchers with patients suffering traumatic injuries, practitioners responding to Code Blues (cardiac arrest), aides performing CPR, technicians drawing blood and performing EKGs, nurses soothing crying babies, etc. Most healthcare workers in the ER find themselves standing for 12-16 hour shifts, having only five minutes to quickly eat a bite for lunch, and purposefully avoiding water consumption to minimize bathroom breaks. Granted, as hectic as it may sound, there are built-in systems in place that allow the department to run as smoothly as possible.
Before pursuing engineering, I was a pre-medical student at my university. Eager to gain experience in the medical field, I gained employment in ER settings where I served as both a Medical Scribe and as an Emergency Room Medical Technician, allowing me to work directly under physicians and be hands-on with patients. My perspective of hospitals as a patient had expanded to that of a staff member; as a result, I was able to understand many uncertainties that we are left to trust in our providers, such as the cause behind such long wait times.
There is, however, a team of staff members who share one common goal: providing the best care possible for patients in need. Even through difficulties, they continue to show up each day to treat, heal, and save lives through treatment and stabilization of urgent medical issues. The exposure I acquired allowed me to recognize the overlap between the fields of medicine and computer science, particularly in the laying of their foundations.
In a symphonic-like structure, each individual — from doctors, nurses, technicians, and housekeeping, to even registration — has a specific role that contributes towards an orchestrated outcome that maintains efficiency through collaborative efforts. Likewise, in the world of software development, there are web frameworks put in place to ensure structure in what could otherwise be considered code that would be chaotic to understand (imagine thousands of lines of code for a whole application built in one or two files).
Adopting a Design Pattern for Web Frameworks
There are several application architectures for web development, but we will focus on MVC — or Model, View, and Controller — which uses specific conventions to prioritize organization and separation of concerns among files. Essentially, each component holds certain information and uses it to communicate: View files directly with the Controller files, and Controller files with Model classes.
Similar to the flow of the emergency department, the regulatory mechanism can minimize potential bugs from affecting the experience of an application user, and facilitate clean code that any other developer would be able to easily interpret.
Understanding MVC Principles for Ruby on Rails
Imagine arriving at an emergency room due to experiencing an acute symptom, such as the headache mentioned earlier. We can use this analogy to understand this design pattern of web frameworks in programming. Here are the three components:
Our model classes consist of 1) you, the Patient, 2) the headache you are experiencing (aka the Chief Complaint), and 3) the ER Visit itself. Upon completion of registration and triage, your acuity is established and saved in the database, along with the models. While you are seated in the waiting room, let’s review the model’s functions:
- Hosts all of the logic for the encounter/application
- Associates the relationships of the classes with each other
- Retrieves requested information from the database
- Receives correspondence from the controller
Your name is called, and you quickly follow the nurse from the congested waiting area — where your headache began to worsen — to your designated evaluation room, where you are informed that the provider will arrive shortly. As you change into a gown, lay in bed, and observe your surroundings of the cold, quiet room, you acknowledge that it’s likely you’ll be waiting for a while. All that can be seen is what comes through the room’s door. The space serves as your view for the duration of the encounter. In this scenario, the patient room acts as your browser screen: where you actually see the doctor, have the physical exam be performed, and present your illness. The view files:
- Displays content for the user to see in the browser
- Accesses Ruby through embedding
- Communicates with controller files
Once you are assessed by a physician, he returns to his station alongside other nurses and staff. You await relief of your headache from your room, meanwhile: techs are completing diagnostic tests, scribes are documenting the findings of the review of systems and physical exam, the doctor is reviewing the results and communicating with nurses about the treatment plan, and the nurses are retrieving and administering the medication for your pain. The nurses’ station is like the controller. Here, it:
- Manages the code flow and request/response navigation
- Receives requests from the client (browser)
- Renders responses to be displayed, through the View
- Redirects paths/routes from one to another
- Manipulates the Model to gather requested data
- Facilitates CRUD (create, read, update, and destroy) functionality
This framework, MVC, is essential in delegating specific concerns to each particular file when building a web application. Now that you understand its purpose, the next time you find yourself in an emergency department, you’ll be able to acknowledge that amongst the perceived madness, there is actually a systemic method in place functioning exactly as it should.