MVC(Model-View-Controller)를 음료 주문에 비유하기

https://medium.com/free-code-camp/model-view-controller-mvc-explained-through-ordering-drinks-at-the-bar-efcba6255053

Model-View-Controller (MVC) Explained Through Ordering Drinks At The Bar

If you have been to a bar, then MVC ain’t that hard.

당신이 바에 가봤다면, MVC는 어렵지 않습니다.

 

Model-view-controller (MVC) frameworks are a crucial part of building modern web applications. Walk into a room of web developers, and you will likely be bombarded with mentions of Ruby on Rails, Angular or Django.

 

More generally, MVC logic can be used to describe almost any web development process that uses a language like PHP, Ruby, Python or JavaScript.

 

모델-뷰-컨트롤러(MVC) 프레임워크는 현대의 웹 애플리케이션을 구축하는 데 있어서 중요한 부분입니다. 여러분이 웹 개발자들의 방에 간다면 Ruby on Rails, Angular이나 Django에 대한 언급이 빗발칠 것입니다.

 

일반적으로 MVC 로직은 PHP, 루비, 파이썬이나 자바스크립트 같은 언어를 사용하는 거의 모든 웹 개발 프로세스를 설명하는 데 사용될 수 있습니다.

 

Ruby on Rails, Angular, Django?

Ruby on Rails는 Ruby를 사용하는 웹 프레임워크로 덴마크의 David Heinemeier Hansson이 오픈 소스로 만들었다. 줄여서 Rails나 RoR이라고도 부른다. 풀 스택 웹 프레임워크이고, non full-stack 웹 프레임워크로는 Sinatra 등이 있다.

앵귤러(Angular, Angular 2+ 또는 Angular v2 이상)는 구글의 앵귤러 팀과 개인 및 기업 공동체에 의해 주도되는 타입스크립트 기반 오픈 소스 프론트엔드 웹 애플리케이션 프레임워크이다.

Django는 2005년부터 시작된 Python의 오픈 소스 웹 프레임워크이자 풀 스택 프레임워크이다.

 

Never the less… 그럼에도 불구하고…

Many web developers navigate this mysterious world by hacking through the weeds with a smile on their face. When a senior developer or teammate needs to look at the code from one of these developers, they will give an immediate yelp, followed by a swift lecture on common coding practices.

 

This is no way to go through life! In fact, the MVC pattern in modern web development can be easily explained by ordering a drink from a bartender. And yes, that means if you have been to a bar, then you can understand the major structural pattern shared by all web apps.

 

많은 웹 개발자들이 미소를 짓고 수풀을 헤치며 이 신비로운 세계를 탐험합니다. 시니어 개발자나 팀원이 이러한 개발자 중 한명의 코드를 보려고 할 때, 그들은 바로 비명을 지르며 일반적인 코딩 관행에 대해 설명하려할 것입니다.

 

이것은 인생을 헤쳐나가기 위한 방법이 아닙니다! 사실 현대 웹 개발의 MVC 패턴은 바텐더에게 음료를 주문하면 쉽게 설명할 수 있습니다. 그렇습니다. 바에 가봤다면, 보든 웹 앱이 공유하는 주요한 구조 패턴을 이해할 수 있을 것입니다. 

 

 

What is the MVC Pattern? MVC 패턴이 무엇인가?

• Model: Structures your data in a reliable form and prepares it based on controller’s instructions
• View: Displays data to user in easy-to-understand format, based on the user’s actions
• Controller: Takes in user commands, sends commands to the model for data updates, sends instructions to view to update interface.

 

• 모델: 신뢰할 수 있는 형태로 데이터를 구성하고 컨트롤러에 지시에 따라 데이터를 준비합니다.
• 뷰: 사용자의 행동에 따른 데이터를 이해하기 쉬운 형식으로 표시합니다.
• 컨트롤러: 사용자 명령을 받아, 모델에게 데이터 업데이트를 위한 명령을 보내고, 뷰에게 인터페이스 업데이트를 위한 지시를 보냅니다.

 

Or, in diagram form:

이를 다이어그램으로 나타내면,

 

사용자 명령을 받는 컨트롤러를 중심으로/모델은 데이터베이스와 소통하며 사용자 요청에 맞는 데이터를 구성하고/뷰는 사용자가 이해하기 쉬운 형식으로 데이터를 보여준다.

That was boring. Onto the bar. 

A beginner web developer enters a bar… 초보 웹 개발자가 바에 간다면...

You enter a bar on a Friday night, and approach the bartender. Since the bar is already crowded, you push through a crowd until you finally catch the bartender’s attention, and you blurt out, “One Manhattan, please!”

 

You are the user, and your drink order is the user request. To you, the Manhattan is just your favorite drink, and you pretty reliably know that this will be a sweet and delicious drink.

 

The bartender gives you a quick nod. To the bartender, the Manhattan is not a tasty drink, it is merely a series of steps:

 

금요일 밤 여러분은 바에 들어가서 바텐더에게 다가갑니다. 만약 바가 이미 붐빈다면, 바텐더가 쳐다보게 하기 위해 사람들을 밀어내고 "맨해튼 하나요!"라고 외치겠죠.

 

여기서 여러분은 사용자이고 음료 주문은 사용자 요청입니다.

 

바텐더는 고개를 바로 끄덕입니다. 바텐더에게 있어서 맨해튼은 맛있는 음료라기 보단 다음과 같은 일련의 단계일 뿐입니다. 

 

1. Grab glass 유리잔을 집고,
2. Add whiskey 위스키를 넣고,
3. Add vermouth 베르무트를 추가합니다.
4. Add bitters 비터를 추가하고,
5. Stir drink 음료를 젓습니다.
6. Add cherry 체리를 넣고, 
7. Ask for credit card and charge. 신용카드를 요구하고 요금을 청구합니다.

The bartender’s brain is the controller. As soon as you say the word “Manhattan” in a language that they understand, the work begins. This work is similar in nature to making a margarita or strawberry daiquiri, but uses distinct ingredients that will never be confused. The bartender can only use the tools and resources that are behind the bar. This limited tool set is the model, and includes the following:  

 

바텐더의 뇌는 컨트롤러입니다. 여러분이 그들이 이해할 수 있는 언어로 "맨해튼"을 외친 순간 작업이 시작됩니다. 이는 본질적으로 마가리타나 딸기 다이키리를 만드는 것과 비슷하지만, 절대 헷갈리지 않을 독특한 재료들을 사용합니다. 바텐더는 바 뒤에있는 도구와 재료만 사용할 수 있습니다. 이 한정된 도구 세트가 모델(model)이며, 다음과 같은 것들을 포함하고 있습니다.

 

• Bartender’s hands 바텐더의 손
• Shakers/mixing equipment 쉐이커, 믹싱 장비
• Liquors 주류
• Mixes 믹스
• Glasses 술잔들
• Garnishes 장식

Perhaps at a fancier bar, they might have a robot assistant! Or an automatic drink mixer. It does not matter to your particular bartender, who can only use the available resources.

 

Finally, the finished drink that you can see and consume is the view. The view is built out of the limited options from the model, and arranged and transmitted via the controller (that is, the bartender’s brain).

 

아마도 더 좋은 바에선, 로봇 어시스턴스가 있을 수 있습니다! 음료 믹서기가 있을 수도 있죠. 하지만 사용 가능한 자원만 사용할 수 있는 특정 바텐더에겐 별로 의미 없습니다. 

 

마지막으로, 완성된 음료가 바로 뷰(view)입니다. 뷰는 모델에서 제한된 옵션으로 구축되며, 컨트롤러(=바텐더의 뇌)를 통해 정돈되고 전송됩니다. 

 

Lessons Learned 배운것들

• Want another drink? Shouting at your empty glass, the view, will do you absolutely no good. You must talk to the bartender.
• The time spent between the bartender hearing the request and starting to create the drink should be absolutely minimal. This is sometimes known as a “skinny controller”- in other words, the controller should contain a minimal amount of logic, and delegate as much as possible to the model. A great bartender will not only have recipes memorized, but will also prepare the ingredients and tools in a reliable manner every night so that a minimal amount of searching and arranging is needed once the customers start ordering.
• Could the bartender pour all the ingredients directly in the customers mouth and expect the customer to swish it around and mix the drink? Yes, possibly I suppose. You want to keep as much of your logic within the model as possible as opposed to within the view. In other words, making the drink behind the bar is preferable to mixing it within the customer’s mouth.

• If you order a beer, the bartender will hardly need to do anything. Perhaps they will simply remove the cap and hand you the drink. That being said, you still must request the bartender. The beer will not magically appear in front of you.

 

• 한 잔 더 할래? 빈 잔, 즉 뷰를 보고 이렇게 외치는 것은 여러분에게 전혀 도움되지 않습니다. 여러분은 바텐더에게 얘기해야 하죠.
• 바텐더가 요청을 듣고 음료를 만들기까지 걸리는 시간을 절대적으로 최소화되어야 합니다. 이것은 "skinny controller"라고 알려져 있습니다. 즉, 컨트롤러는 최소한의 로직만을 포함하고, 나머진 가능한한 모델에 위임되어야합니다. 훌륭한 바텐더는 레시피를 기억할뿐만 아니라 매일 밤 재료와 도구를 신뢰성있게 준비하여 고객이 주문하면 최소한의 검색과 정돈을 해야합니다.
• 바텐더가 모든 재료를 손님의 입에 직접 쏟고 고객이 그 재료들을 직접 섞길 기대할 수 있을까요? 네, 아마도 그럴 순 있겠죠. 여러분은 뷰에는 없는 가능한한 많은 로직을 모델에 넣고 싶을 것입니다. 즉, 바 뒤에서 음료를 만드는 것이 손님의 입안에서 재료를 섞는 것보다 더 바람직합니다.

• 여러분이 맥주를 주문해면 바텐더는 아무것도 할 필요가 없을 것입니다. 아마도 그들은 그냥 뚜껑을 열고 당신에게 음료를 건네줄 것입니다. 그렇긴해도, 여러분은 여전히 바텐더에게 요청을 해야합니다. 맥주가 마법처럼 눈앞에 나타나진 않기 때문이죠.

 

Tying It Back To Web Development 웹 개발로 돌아가서

Here is how the same process plays out in a modern web app:

• The user makes a request along a route, let’s say /home.
• The controller receives this request and gives a specific set of orders that are related to that route. These instructions could either be for the view to update or serve a certain page, or for the model to perform specific logic. Let’s assume this request has some logic associated with it.
• The model carries out the logic, pulls from a database and sends back a consistent response based on the controller’s instructions.
• The controller then passes this data to the view to update the user interface.

웹 앱에서 동일한 프로세스가 수행되는 방식은 다음과 같습니다.

• 사용자가 경로를 따라 요청하는 경우, /home이라고 하겠습니다.
• 컨트롤러는 이 요청을 받고 해당 경로와 관련된 순서셋을 제공합니다. 이러한  지시는 뷰가 특정 페이지를 업데이트하거나 서비스하기 위한 것일 수도 있고, 모델이 특정 로직을 수행하기 위한 것일 수도 있습니다. 이 요청과 관련된 로직이 있다고 가정해봅시다.
• 모델은 로직을 수행하고, 컨트롤러의 지시에 따라 데이터베이스에서 가져온 일관된 응답을 보냅니다. 
• 그런다음 컨트롤러는 사용자 인터페이스를 업데이트 하기위해 뷰에 데이터를 보냅니다.

 

Whenever a request comes in, it first must go to the controller before it can be converted into instructions for the view or model. The Ruby on Rails wikipedia article contains a further overview if you are looking for more.

 

Any time you need to learn a new web development framework, you will come across this consistent MVC pattern. And if a particular framework differs from this, you can be sure that the authors will explain their new pattern with references to MVC.

 

This should make learning a heck of a lot easier- once you develop with MVC once, every new framework can fit within your comfort zone.

 

요청이 들어올 때마다 먼저 컨트롤러로 이동한 후에야 뷰나 모델에 대한 지시로 변환할 수 있습니다. 더 많은 것을 알고 싶으시면 "Ruby on Rails 위키백과 기사"에  더 많은 개요가 있습니다. 

 

여러분이 새로운 웹 개발 프레임워크를 배워야 할 때마다, 이 일관된 MVC 패턴을 보게 될 것입니다. 그리고 만약 특정한 프레임워크가 이것과 다르다면, 여러분은 제작자가 MVC를 참고하여 그들의 새로운 패턴을 설명할 것이라고 확신할 수 있습니다. 

한 번 MVC를 사용해 개발하고나면 무엇이든 쉽게 익힐 수 있습니다. 여러분은 모든 새로운 프레임워크를 능숙하게 다룰 수 있을 것입니다.