프로그래머가 아닌 사람에게 MVC를 설명해야합니다. 즉, 진행 보고서의 맥락에서 다른 부서의 관리자에게. 내가하는 일 중 하나는 코드베이스를 MVC 분리로 리팩터링하는 것입니다.

그들이 요청할 수도있는 MVC 분리는 무엇입니까? 그들이 물어볼 필요가있는 이유는 무엇입니까?

다음과 같이 상당히 기술적 인 답변을 읽은 후에 실제로 MVC 란 무엇입니까? 나는 프로그래머가 아닌 사람들과 대화 할 것이기 때문에 완전히 만족하지는 않는다. 그들은 고개를 끄덕 일지 모르지만 아마도 그것이 무엇이고 왜 필요한지 이해하지 못할 것입니다.

실제로, 저는 소프트웨어 변경의 유연성을 향상시키기 위해 MVC가 관심사, 의무, 기능, 클래스, 블록, 작업, 사물 분리라는 것 이외의 다른 것을 완전히 파악하지 못합니다. DI 및 OO 도구 및 기술과 같은 기술을 사용하여 비즈니스 로직에서 데이터베이스를 뷰에서 분리하는 것은 MVC 분리로 간주됩니다.

다음에 영업 및 회계에 대한 배경 지식이없는 프로그래머가 아닌 사람에게 MVC를 설명 할 때는 무엇을 말 하시겠습니까?

당신은 MVC를 설명하지 않습니다.

당신이하는 일은 이것이 코드베이스의 재구성이라는 것을 설명하는 것입니다.

코드베이스를 단순화하여 개발자가 버그를 줄이고 버그 보고서 및 기능 요청을 더 빠르고 효과적으로 변경할 수있는 구조 조정.

기술적 인 세부 사항, 그 이유, 수행 한 결과 및 비즈니스 이점을 알 필요가 없습니다.

다시 말해, 그들에게 언어를 말하십시오.

Oded의 답변 의 요점을 보증하는 동안 , "그들의 언어"로 비즈니스 관리자에게 기술 프로젝트를 설명해야한다고 나는 "그들은 기술적 인 세부 사항을 알 필요가없고, 그 이유는 무엇인가"에 대한 기사를 가지고 있습니다.

부서장과 프로젝트 또는 투자 검토 회의에 참여하고 있고 "이것이 우리가하는 일"이라고 선언 한 경우, "음 ... 왜? 그것은 시간과 에너지에 큰 투자 인 것 같습니다. 당신이하고있는 일과 이유를 좀 더 이해해 주시겠습니까? " 그것은 상당히 합리적인 질문 인 것 같습니다. 당신은 "음 ... 복잡하다."라는 입장에 빠지기를 원하지 않습니다. 또는 "아니요, 정말 설명 할 수 없습니다." 또는 "걱정하지 마십시오." 프로젝트 검토를 수행하는 직원이 많을수록 "잘 설명 할 수없는 것"일 가능성이 줄어 듭니다. 다른 사람이 편안하게 느끼도록 적어도 한 단계 더 깊이 갈 수 있다면 더 좋습니다. 1) 자신이 무엇을 알고 있는지

따라서 엉덩이 주머니에 MVC를 스케치하고 준비하십시오. 다음과 같은 것 :

"그것은 약간 기술적이지만 MVC는 코드를 모델 (핵심 데이터 및 비즈니스 논리에 책임이있는), 뷰 (데이터를 표시하는) 및 컨트롤러 (사용자 상호 작용 및 업데이트를 처리하는)로 나눕니다. 입증 된 아키텍처입니다. 아마도 소프트웨어 엔지니어링에서 가장 성공적인 "디자인 패턴"인 것 같습니다. "어떤 배관공처럼"보일지 모르지만 들어오는 모든 요청을 처리하려면 더 강력한 기반이 필요합니다. 기능과 버그를 더 빨리 해결합니다. "

MVC가 끝날 때 MVC를 완전히 이해하지 못하고 이해하기 쉽도록 너무 단순화해야하더라도 ( "오믈렛을 만들기 위해 계란을 부수십시오"), 나는 더 편하게 찾을 수 있습니다. 선임 관리자에게 "설명 할 수 없습니다"또는 "이를 이해할 자격이 없습니다"라고 말하는 것보다 설명이 필요합니다.

소프트웨어 변경의 유연성을 향상시키기 위해

관리자는 최종 결과에 관심이 있습니다. 기술이 적을수록 귀하가 어떻게 가는지에 대한 관심이 적습니다. MVC는 매우 일반적이며 인기가 높으며 입증되었습니다.

향후 변경 요청이있을 경우 더 쉽고 빠르게 변경할 수 있음을 관리자에게 알릴 수 있습니다. 모두들이 말을 좋아합니다.

일반적인 전략이므로 새로운 개발자를 고용해도 문제가되지 않습니다. 사실, 강력한 지지자 인 더 나은 개발자를 유치 할 수 있습니다.

이 특정 프로젝트에 많은 긴급한 문제가 있다면 이것은 매우 어려울 것입니다. 한 걸음 물러나서 두 단계 앞으로 나아갈 수는 없습니다. 해결책은 더 작은 조각으로 기다리거나 구현하는 것일 수 있습니다.

• 모델-전선 / 전기
• 전망-전등 설비
• 컨트롤러-전등 스위치

구성 요소를 쉽게 전환 할 수 있습니다 (조명기구, 조명 스위치 / 조광기). 배선은 그리 많지 않지만 다른 구성 요소에 영향을 미치지 않고 여전히 수행 할 수 있습니다. 모든 사람은 마케팅 / 판매 유형까지도이를 시각화 할 수 있어야합니다. (클리어 분리 등)

이제 상사 / 동료들에게 우리의 응용 프로그램 / 시스템에서 스위치가 전등 내부에 내장되어 있고 전등이 구리선으로 둘러싸여 있다고 말합니다. 이제 조명기구, 스위치 또는 와이어를 업데이트하려고합니다. 비용이 많이 들며 다른 구성 요소에 미치는 영향은 매우 높으며 다른 요소를 손상시키지 않으면 서 위험 할 수 있습니다.

MVC는 코드베이스에 패턴을 적용하여 혼란스러운 (그러나 작동하는) 혼란을 적은 오류로 더 빠르고 쉽게 변경할 수있는 것으로 바꿉니다.

쉬운 방법은 이해하기 MVC를 : 모델은 데이터입니다 , 보기 화면의 창입니다 , 그리고 컨트롤러가 둘 사이의 접착제입니다 .

최고의 루 브릭 : "우리는 SMART 모델, THIN 컨트롤러 및 DUMB 뷰가 필요합니다."

다른 소프트웨어 디자인 패턴과 마찬가지로 MVC 는 각 솔루션에 적용 할 수 있도록 " 솔루션의 핵심 "을 문제로 표현합니다 . 특정 구현 대신 개념으로 더 잘 나타납니다. 이 개념에는 많은 구현이 있습니다.

모든 MVC 변형은 동일한 구성 요소를 사용하지만 일반적으로 이러한 구성 요소의 상호 작용 방식이 다릅니다.

모르는 분들을 위해 MVC는 1979 년 Trygve Reenskaug의 Smalltalk 와 함께 사용하기위한 디자인 패턴으로 설명되었습니다 . 그의 논문은 "Smalltalk-80에서의 애플리케이션 프로그래밍 : Model-View-Controller 사용 방법"이라는 제목으로 출판되었으며, 미래의 MVC 구현을위한 토대를 마련했습니다.

저는 Oded와 반쯤 동의합니다. 기술이 아닌 동료 및 관리자에게 당신이하고있는 일이 중요하고 유용하며, 세부적인 내용을 설명하지 않고 개발하는 데 필요한 기술이라고 확신시키는 방법을 배우십시오.

그러나 복잡한 개념을 간단한 용어로 설명 할 수있는 능력 이 실제로 도움이된다고 생각합니다. 비 기술적 인 관리자는 종종 기술 담당자가하는 일을 정확히 이해하는 데 어려움이 있기 때문에 그들을 불신. 그것은 단지 인간의 본성입니다. 이해하지 못하는 것이 믿음을 두는 것보다 쓸모 없거나 잘못되었다고 믿는 것이 더 쉽습니다. 따라서 개념을 마음대로 이해하기 쉽게 만들 수 있다면 필요할 때마다 사용할 수 있으며, 시간이 지남에 따라 기술이 아닌 관리자는 원하는 경우 개념을 이해할 수 있음을 알게됩니다. 그들-당신은 그들에게 자신의 정신에 대한 세부 사항을 절약하고 있습니다. 그들은 당신을 더 신뢰합니다.

그 옆에 질문에 대답합시다.

비즈니스 사람들이 이해하는 비유를 사용하는 것이 유용하다는 것을 알았습니다. MVC의 경우 비즈니스로 설명합니다.

• 모델 은 비즈니스 로직과 데이터를 담당합니다. 프로그램의 기능과 프로그램의 세부 사항을 정의하는 것입니다. 프로그램이 사업 이었다면 모델은 창고, 공장, 노동자 및 자본 장비가 될 것입니다. 또한 규칙을 준수하고 정책이 시행되도록하는 하위 관리자이기도합니다.
• 뷰 는 프리젠 테이션 레이어입니다. 시스템에서 진행중인 작업을 사용자에게 보여주고 프로그램과 상호 작용하는 수단을 제공합니다. 우리의 프로그램이 회사라면, 전시장, 무역 컨벤션의 영업 부스 또는 영업 담당자와 같은 견해가 있습니다. 옵션을 표시하고 사용자에게 친숙한 정보와 피드백을 제공하며 회사에 다시 요청합니다.
• 컨트롤러 는 조정 계층입니다. 정보가 모델에서 뷰로 또는 그 반대로 전달되고 모든 것이 함께 작동하여 작업을 수행하도록합니다. 프로그램이 회사라면 컨트롤러는 중급 및 고급 관리가 될 것입니다. 그들은 세부 사항에 너무 관여하지 않지만 올바른 사람들이 자신의 업무를 수행 할 수있는 올바른 도구를 가지고 있는지 확인하고 높은 수준의 결정을 승인하거나 거부합니다. 그들은 함께 일할 수 있도록 전반적인 방향을 제공합니다.

이 비유를 통해 설명 할 때의 이점은 훌륭한 관리자가 이러한 방식으로 문제를 분리하는 데 필요한 지혜를보고 더 많은 컨트롤러와 비슷해야하며 앞으로 세부 사항에 너무 많이 관여하지 않도록 결정할 수 있다는 것입니다!

희망은 "무엇"에 대답 할 것입니다- "이유"는이 비유로도 쉽습니다 :

각 부서가 하나의 작업 세트를 담당하는 이상적인 회사를 상상하고 다른 회사의 업무에 대해 걱정할 필요없이 항상 필요한 리소스를 보유하고 있다는 것을 알고 있습니다. 영업 담당자는 고객을 찾고 주문을 받고 승인 한 관리자에게 다시 전달한 다음 이행을 위해 창고 / 생산 / 엔지니어링으로갑니다. 피드백은 직접적입니다. 문제가 없으면 다른 사람이 관여 할 필요가 없습니다. 그것은 좋은 MVC 디자인입니다-각 부분에는 직업이 있으며 다른 부분에 대해 걱정할 필요가 없습니다. 그렇게하면 필요한 경우 쉽게 변경할 수 있습니다. 비 MVC 설계에서는 책임이 명확하지 않습니다. 고객이 다른 것을 요청할 때 영업 담당자가 제품을 수정하려고 할 수 있습니다. 또는 그 날 느낌에 따라 가격이 달라질 수 있습니다. CEO는보다 안정적인 공급망을 확보하는 방법에 대해 걱정해야 할 때 생산 라인을 뒤죽박죽 공장 현장에 빠뜨릴 수 있습니다. 창고 작업자가 고객이 이미 수행 한 주문을 이행해야 할 때 고객과 ​​이야기하는 영업 현장에있을 수 있습니다.

다시 말해, 우수한 MVC 디자인은 각 부품이 한 가지에 집중할 수있게하여 잘 조직 된 회사처럼 올바르게 수행 할 수 있도록합니다.

** 면책 조항-회사가 제대로 구성되어 있지 않으면 이로 인해 기분이 상할 수 있습니다. 이 경우 다른 비유가 필요합니다. 다른 직업이 필요할 수도 있습니다.

MVC의 장점은 주로 관심사 분리에 있습니다.

사람들이 자신이하는 일에 집중할 수 있습니다.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

얽힌 시스템은 직원이 이러한 모든 영역의 전문가 여야하므로 한 영역의 변경이 다른 영역에 영향을 줄 때 문제가 발생할 가능성이 높기 때문에 비용이 절감됩니다.

MVC 아키텍처의 실제 예를 제공하십시오 : 휴대폰, 데스크탑 전화, Skype 등.보기 (다이얼 패드, 스피커, 마이크의 유형)를 변경해도 모델 (오디오 신호)에 영향을 미치지 않습니다. 컨트롤러는 회로입니다. 음파를 오디오 신호로 변환하는 전화.

나는 MVC가 내 관심사를 분리한다고 말합니다.

첫 번째 관심사는 코드 로직입니다. 웹 사이트에서 원하는 작업을 수행 할 수 있도록 배후에서 수행하는 작업입니다.

두 번째 관심사는 비즈니스 로직입니다. 애플리케이션 (사용자)이 원하는 것입니다.

세 번째 관심사는 사이트의 모습입니다. 원하는 페이지를 방문하는 페이지입니다.

(다음 부분에서는 아무 말도하지 않습니다.) 따라서 순서대로 Model, Controller, View에 대한 설명이있었습니다.

장점을 설명

사업상의 이점으로 MVC를 설명하겠습니다. 관리자는이를 이해할 수 있으며 이점이 설득력이있을 경우 탑승 할 수 있습니다.

MVC를 사용하면 응용 프로그램을 적절한 단위로 분류 할 수 있으며 각 단위는 다른 단위와 독립적으로 존재합니다. 깨끗하고 유지 관리 가능하며 테스트 가능한 코드를 얻을 수 있으며 시스템간에 코드를 재사용 할 수 있습니다.

모델

각 모델은 단일 유형의 비즈니스 정보 (예 : 고객 레코드 또는 제품)를 모든 관련 비즈니스 논리와 함께 캡슐화합니다.

이를 분리하면 비즈니스 로직을 애플리케이션의 다른 부분과 분리하여 쉽게 테스트 할 수 있습니다.

더 많은 모델을 추가하여 응용 프로그램을 쉽게 확장 할 수 있으며 매우 모듈 식이며 깔끔합니다.

이론적으로 각 모델은 다른 모델과 독립적으로 존재할 수 있습니다. 서비스 개체를 사용하여 모델 간의 관계를 처리하여이를 적용하는 것을 고려할 수 있습니다. 나머지 시스템에 영향을주지 않고 모델을 교체 할 수 있습니다.

보기

뷰를 분리하면 기본 백엔드를 손상시키지 않고 프런트 엔드를 쉽게 업데이트 할 수 있습니다.

전체 시스템에 대한 액세스 권한을 부여하지 않고도 다른 개발자에게 프론트 엔드 코드를 제공 할 수 있습니다.

기존 시스템과 호환되는 대체 프런트 엔드를 자유롭게 만들 수도 있습니다. 데이터를 모바일 앱, API, PDF 또는 Excel 스프레드 시트로 표시 할 수 있습니다. 나머지 시스템을 해킹하지 않고도이 작업을 수행 할 수 있습니다. 실수로 물건을 깰 가능성이 적습니다. 기존 시스템에 연결할 통합 지점을 쉽게 만들 수 있습니다.

컨트롤러

컨트롤러는 모델을 뷰에 연결합니다. 모든 것을 분리하여 유지합니다. 다른보기에서 매우 쉽게 연결할 수 있습니다. 모델 코드를 변경하면 뷰를 알 필요조차 없습니다.

다른 장점

일반적인 패턴입니다. 다른 개발자는 코드를 이해하고 작업 할 수 있습니다. 몇 년 후 코드로 돌아 가면 코드를 이해하고 변경할 수있을 것입니다. 코드는 미래 개발자에게 또 다른 레거시 두통이 될 가능성이 적습니다.

모든 것이 장소가 있기 때문에 깨끗한 코드를 생성하는 것이 훨씬 쉽습니다. 스파게티 화의 위험이 크게 줄어 듭니다 (제거되지는 않지만). 코드를 유지 관리 할 수있게됩니다.

모든 것이 모듈 식이므로 일부를 개별적으로 테스트 할 수 있습니다. 코드를 테스트 할 수 있으며 버그 나 보안 허점을 덜 일으킬 수 있습니다. 전체 시스템을 쉽게 테스트 할 수 있으므로 향후 업그레이드가 훨씬 쉬워집니다.