"MVC"의 "컨트롤러"에 들어가는 내용은 무엇입니까?

"MVC"의 "컨트롤러"에 들어가는 내용은 무엇입니까?

MVC의 기본 개념은 이해합니다. 모델은 애플리케이션의 데이터와 동작을 포함하고, 보기는 사용자에게 표시할 책임이 있으며, 컨트롤러는 사용자의 입력을 처리합니다.내가 확신할 수 없는 것은 컨트롤러에서 정확히 무엇이 이루어지느냐이다.

예를 들어, 매우 단순한 어플리케이션이 있다고 합시다(특히 Java를 생각하고 있습니다만, 그 외의 장소에서도 같은 원리가 적용됩니다).나는 내 코드를 3개의 패키지로 정리한다.app.model,app.view그리고.app.controller.

내부app.model패키지, 어플리케이션의 실제 동작을 반영하는 클래스가 몇 개 있습니다.이것들extends Observable및 사용setChanged()그리고.notifyObservers()적절한 경우 보기를 업데이트하도록 트리거합니다.

그app.view패키지에는 다음과 같은 클래스(또는 다른 유형의 디스플레이를 위한 여러 클래스)가 있습니다.javax.swing디스플레이를 처리하는 컴포넌트.이들 컴포넌트 중 일부는 모델에 피드백해야 합니다.제가 올바르게 이해한 경우, 보기는 피드백과 아무런 관련이 없으며, 이는 장관이 처리해야 합니다.

그럼 컨트롤러에는 실제로 무엇을 넣어야 할까요?제가 이걸 넣어야 돼요?public void actionPerformed(ActionEvent e)컨트롤러의 메서드를 호출하는 것만으로 뷰에 표시할 수 있습니까?만약 그렇다면 장관 내에서 검증 등을 실시해야 하는가?이 경우 오류 메시지를 View로 피드백하려면 어떻게 해야 합니까? 다시 모델을 통과해야 합니까? 아니면 컨트롤러가 View로 바로 돌려보내야 합니까?

View에서 검증을 수행할 경우 컨트롤러에 무엇을 넣어야 합니까?

질문이 길어서 죄송합니다.저는 단지 프로세스에 대한 이해를 문서화하고 싶었을 뿐입니다.누군가 이 문제를 명확하게 해 주셨으면 합니다.

제안하신 예시는 맞습니다.인터페이스의 "user clicked this item" 버튼은 기본적으로 컨트롤러의 "delete" 기능만 호출하면 됩니다.그러나 컨트롤러는 뷰가 어떻게 표시되는지 알 수 없으므로 뷰는 "클릭된 항목"과 같은 정보를 수집해야 합니다.

대화 형식:

보기: "컨트롤러님, 방금 사용자가 항목 4를 삭제하라고 했습니다."
컨트롤러: "음, 그의 자격증을 확인한 결과, 그는 그것을 할 수 있었습니다...모델님, 4번 아이템을 가져와 삭제하기 위해 무슨 짓이든 해 주세요."
모델: "아이템 4...알겠습니다.삭제되었습니다.다시 연락드리겠습니다, 컨트롤러님."
컨트롤러: "여기서 새로운 데이터 세트를 수집합니다.다시 찾아뵙겠습니다.
보기: "좋아, 이제 새로운 세트를 사용자에게 보여줄게."

이 섹션의 마지막에는 뷰가 "최신 데이터 세트를 주세요"라는 개별 요청을 생성하여 보다 순수해지거나 컨트롤러가 "삭제" 조작으로 새로운 데이터 세트를 암묵적으로 반환할 수 있는 옵션이 있습니다.

에 관한 문제MVC사람들은 뷰, 컨트롤러 및 모델이 서로 최대한 독립적이어야 한다고 생각합니다.뷰와 컨트롤러가 서로 얽혀 있는 경우가 많습니다.이것을M(VC).

컨트롤러는 사용자 인터페이스의 입력 메커니즘으로, 특히 GUI와 함께 뷰에 얽혀 있는 경우가 많습니다.단, 뷰는 출력되고 컨트롤러는 입력됩니다.뷰는 대응하는 컨트롤러 없이 동작하는 경우가 많지만 뷰가 없으면 컨트롤러의 유용성은 크게 떨어집니다.사용하기 쉬운 컨트롤러는 뷰를 사용하여 사용자의 입력을 보다 의미 있고 직관적인 방식으로 해석합니다.이것이 컨트롤러의 개념을 뷰에서 분리하기 어렵게 만드는 이유입니다.

밀폐된 상자 안에 있는 탐지 영역에 있는 무선 조종 로봇을 모델로 생각해 보십시오.

이 모델은 출력(디스플레이) 또는 상태 전환을 트리거하는 개념 없이 상태 및 상태 전환에 관한 것입니다.필드에서 로봇의 위치를 얻을 수 있고 로봇은 위치를 전환하는 방법을 알고 있습니다(앞/뒤/좌/우 이동).뷰나 컨트롤러 없이 쉽게 상상할 수 있지만 유용한 기능은 없음

예를 들어, 네트워크상의 다른 방에 있는 누군가가 로봇의 위치를 보고 있는 것과 같이 컨트롤러가 없는 뷰를 (x,y)좌표가 스크롤 콘솔을 타고 흘러내린다고 생각해 보십시오.이 뷰는 모델 상태를 표시하는 것일 뿐이지만 이 뷰에는 컨트롤러가 없습니다.이 화면은 컨트롤러 없이 쉽게 상상할 수 있습니다.

시야가 없는 컨트롤러를 생각해 보십시오. 예를 들어, 누군가가 로봇의 주파수에 맞춰 라디오 컨트롤러를 옷장에 잠근 경우입니다.이 컨트롤러는 입력 정보를 전송하여 모델에 대해 무엇을 하고 있는지(있는 경우) 알 수 없는 상태 천이를 일으킵니다.상상하기는 쉽지만, 뷰의 피드백이 없으면 도움이 되지 않습니다.

대부분의 사용자 친화적인 UI는 보다 직관적인 사용자 인터페이스를 제공하기 위해 보기를 컨트롤러와 조정합니다.예를 들어, 로봇의 현재 위치를 2-D로 보여주는 터치 스크린이 있는 보기/컨트롤러를 상상해 보십시오. 사용자가 화면상의 로봇 앞에 있는 지점을 터치할 수 있습니다.컨트롤러는 이를 올바르게 해석하기 위해 뷰포트의 위치 및 축척, 화면에서 로봇의 픽셀 위치를 기준으로 터치된 지점의 픽셀 위치와 같은 뷰에 대한 세부 정보가 필요합니다(무선 컨트롤러로 옷장에 잠긴 사람과 다릅니다).

제가 당신의 질문에 대답했나요? :-)

컨트롤러는 모델을 이행 상태로 만드는 데 사용되는 사용자로부터 입력을 받는 모든 것입니다.뷰와 컨트롤러를 분리해 두되, 상호의존하고 있는 경우가 많기 때문에 경계가 애매한 경우, 즉 뷰와 컨트롤러를 다른 패키지로 하는 경우, 원하는 만큼 깔끔하게 분리할 수는 없지만 괜찮습니다.뷰가 모델에서 분리되어 있기 때문에 컨트롤러가 뷰에서 완전히 분리되지 않는다는 점에 동의해야 할 수 있습니다.

...장관의 검증 등을 실시해야 하는가?이 경우 오류 메시지를 View로 피드백하려면 어떻게 해야 합니까? 다시 모델을 통과해야 합니까? 아니면 컨트롤러가 View로 바로 돌려보내야 합니까?

View에서 검증을 수행할 경우 컨트롤러에 무엇을 넣어야 합니까?

링크된 뷰와 컨트롤러는 모델을 거치지 않고 자유롭게 상호작용해야 합니다.컨트롤러는 사용자의 입력을 받아 검증을 수행해야 합니다(모델 및/또는 뷰의 정보를 사용). 그러나 검증에 실패하면 컨트롤러는 관련 보기를 직접 업데이트할 수 있습니다(예: 오류 메시지).

이에 대한 산성 테스트는 독립된 뷰(즉, 네트워크를 통해 로봇 위치를 감시하는 다른 방에 있는 사람)가 다른 사람의 검증 오류(예: 옷장 안에 있는 사람이 로봇에게 필드를 벗어나라고 지시한 결과로서 아무것도 볼 수 있는지 여부를 자문하는 것입니다.일반적으로 "아니오"라고 대답합니다.검증 오류로 인해 상태 전환이 방해되었습니다.상태 변환이 없는 경우(로봇이 움직이지 않음) 다른 보기에 알릴 필요가 없습니다.옷장 안에 있는 남자는 불법적인 이행(뷰 없음 - 사용자 인터페이스 불량)을 일으키려고 했다는 피드백을 받지 못했을 뿐이며, 다른 사람은 그것을 알 필요가 없습니다.

터치스크린을 가진 사람이 로봇을 필드 밖으로 내보내려고 하면 탐지 필드 밖으로 내보내서 로봇을 죽이지 말라는 친절한 메시지를 받았습니다. 하지만 다시 말하지만, 아무도 이것을 알 필요가 없습니다.

다른 뷰에서 이러한 오류에 대해 알 필요가 있는 경우, 사용자로부터의 입력과 그로 인한 오류는 모델의 일부이며, 전체는 조금 더 복잡하다고 말할 수 있습니다.

여기 MVC의 기본에 대한 좋은 기사가 있습니다.

라고 쓰여 있습니다.

컨트롤러 - 컨트롤러는 뷰와의 상호작용을 모델에 의해 실행되는 작업으로 변환합니다.

즉, 비즈니스 로직입니다.컨트롤러는 뷰에서 사용자가 취한 액션에 응답하여 응답합니다.여기서 검증을 수행하고 검증에 실패하거나 성공한 경우(오류 페이지, 메시지 상자 등) 적절한 보기를 선택합니다.

Fowler에는 또 다른 좋은 기사가 있다.

MVC 패턴은 프레젠테이션(= 보기)과 비즈니스 로직(= 모델)을 분리하기를 원할 뿐입니다.컨트롤러 부품은 혼동을 일으킬 뿐입니다.

실제로 컨트롤러의 개념이 특별히 유용한 것은 본 적이 없습니다.코드에 엄격한 모델/뷰 분리를 사용하고 있습니다만, 명확하게 정의된 컨트롤러는 없습니다.그것은 불필요한 추상화인 것 같다.

개인적으로 MVC가 본격화된 것은 자칫 잘못 설계되고 지나치게 복잡한 설계로 이어지기 쉽다는 점에서 공장 설계 패턴처럼 보인다.건축 우주 비행사가 되지 마세요.

컨트롤러는 뷰의 일부입니다.이 기능은 요청을 이행하는 데 필요한 서비스를 파악하고 View의 값을 서비스 인터페이스가 필요로 하는 개체로 변환하고 다음 View를 결정하고 응답을 다음 View에서 사용할 수 있는 형식으로 다시 정렬하는 것입니다.또한 발생하는 예외를 처리하여 사용자가 이해할 수 있는 보기로 렌더링합니다.

서비스 계층은 사용 사례, 작업 단위 및 모델 개체를 알고 있는 계층입니다.컨트롤러는 뷰의 종류에 따라 다릅니다.데스크탑, 브라우저 기반, Flex 또는 모바일 UI에서는 동일한 컨트롤러가 없습니다.따라서 실제로 UI의 일부라고 할 수 있습니다.

서비스 지향: 여기서 작업이 수행됩니다.

질문하신 내용에 따르면 모델 역할에 대해 좀 애매한 것 같습니다.모델은 응용 프로그램과 연결된 데이터에 고정됩니다. 앱에 데이터베이스가 있는 경우 모델의 역할은 해당 모델과 대화하는 것입니다.또한 해당 데이터와 관련된 간단한 로직도 처리합니다. 모든 경우에 대해 TABLE.foo == "Hooray!" 및 TABLE.bar = "Huzzah!"를 설정한 다음 TABLE.field="W00t!"를 설정하는 규칙이 있는 경우 모델이 처리하기를 원합니다.

컨트롤러는 애플리케이션 동작의 대부분을 처리해야 합니다.질문에 답하려면:

컨트롤러의 메서드에 대한 호출만으로 퍼블릭 void action Performed(ActionEvent e)를 View에 넣을 수 있습니까?

아니라고 말하고 싶어요.이는 컨트롤러에 존재해야 합니다. View는 사용자 인터페이스에서 컨트롤러로 데이터를 전송하고 컨트롤러가 응답으로 호출해야 할 메서드를 결정하도록 해야 합니다.

만약 그렇다면 장관 내에서 검증 등을 실시해야 하는가?

검증의 대부분은 컨트롤러가 수행해야 하며, 데이터가 유효한지 여부에 대한 질문에 답변해야 하며, 그렇지 않은 경우 적절한 오류 메시지를 View에 제공합니다.실제로, 당신은 보기 계층에 사용자의 경험을 개선시키는 위해(나는 당신이 어디를 오류 메시지 팝 사용자의 안타"제출하다"보다는 전체 정상 회의 -&gt을 기다릴 거 웹 환경, 과정 -> 부하 페이지 주기는 주로; 말하기 전에 생각하고 있어요 몇가지 간단한 분별력 검사를 통합할 수 있다.my가 망쳤어요.)다만 주의해 주세요.필요한 것보다 더 많은 노력을 하고 싶지 않습니다.많은 환경에서(다시 말씀드리지만 웹을 생각하고 있습니다) 사용자 인터페이스에서 나오는 데이터는 실제 적법하다는 것을 확인할 때까지 더러운 거짓말로 취급해야 합니다.

이 경우 오류 메시지를 View로 피드백하려면 어떻게 해야 합니까? 다시 모델을 통과해야 합니까? 아니면 컨트롤러가 View로 바로 돌려보내야 합니까?

컨트롤러가 지시할 때까지 보기가 다음에 무슨 일이 일어날지 알 수 없는 프로토콜을 설정해야 합니다.사용자가 버튼을 누르면 어떤 화면이 표시됩니까?뷰는 알 수 없고 컨트롤러는 방금 받은 데이터를 보기 전까지 알 수 없습니다."예상대로 이 다른 화면으로 이동" 또는 "이 화면에 남아서 이 오류 메시지를 표시"가 될 수 있습니다.

제 경험상 모델과 뷰 간의 직접적인 커뮤니케이션은 매우 제한적이어야 하며 뷰는 모델의 데이터를 직접 변경하지 않아야 합니다. 이는 컨트롤러가 해야 할 일입니다.

View에서 검증을 수행할 경우 컨트롤러에 무엇을 넣어야 합니까?

위 내용을 참조하십시오. 실제 검증은 컨트롤러에 있어야 합니다.그리고 컨트롤러에 무엇을 넣어야 하는지 알고 계시기를 바랍니다. :- )

소프트웨어 엔지니어링과 같이 복잡한 대부분의 경우, 판단의 요구는 많아지기 때문에, 이 모든 것이 약간 흐릿해질 수 있습니다.최선을 다해 이 앱 내에서 일관성을 유지하면서 배운 내용을 다음 프로젝트에 적용하도록 노력하십시오.

다음은 경험의 법칙입니다.이 페이지에서 작업하기 위해 특별히 사용하는 절차라면 모델이 아닌 컨트롤러에 속합니다.모델은 데이터 스토리지에 일관성 있는 추상화만 제공해야 합니다.

MVC를 이해한다고 생각했지만 실제로는 이해하지 못한 개발자들이 작성한 대형 웹앱을 작업한 후 생각해 낸 것입니다.그 「컨트롤러」는, 8 행의 콜링 스태틱 클래스 메서드로 축소되어 있습니다.이러한 메서드는 다른 곳에서는 사용되지 않습니다:-/라고 불리고 있습니다.이러한 메서드는 모델을 네임스페이스를 만드는 방법보다 조금 더 크게 하지 않습니다.이를 적절하게 수정하면 3가지 작업이 수행됩니다.모든 SQL을 데이터 액세스 레이어(일명 모델)로 전환하고 컨트롤러 코드를 좀 더 상세하게 만들지만 이해하기 쉽게 만들며 오래된 "모델" 파일을 0으로 줄일 수 있습니다. :-

컨트롤러는 주로 뷰와 모델 간의 조정을 위한 것입니다.

아쉽게도 작은 앱에서 보기와 함께 섞이는 경우도 있습니다.그건 나쁘지 않습니다.

다음 내용을 입력해 주세요.

public void actionPerformed(ActionEvent e)

컨트롤러에 있습니다.그런 다음 뷰의 액션청취자가 컨트롤러에 위임해야 합니다.

검증 부분은 뷰나 컨트롤러에 넣을 수 있기 때문에 개인적으로는 컨트롤러에 속해 있다고 생각합니다.

Passive View와 Supervising Present(Power에 의해 모델 뷰 프레젠터가 분할된 것)를 꼭 보시기 바랍니다.참조:

http://www.martinfowler.com/eaaDev/PassiveScreen.html

http://www.martinfowler.com/eaaDev/SupervisingPresenter.html

또한 각 Swing 위젯은 3개의 MVC 컴포넌트를 포함하는 것으로 간주할 수 있습니다.각 컴포넌트는 모델(Button Model), 뷰(Basic Button)가 있습니다.UI) 및 컨트롤(JButton 자체).

컨트롤러에 탑재한 내용은 기본적으로 옳습니다.모델이 보기와 상호 작용해야 하는 유일한 방법입니다.수행된 작업은 보기에 배치할 수 있지만 실제 기능은 컨트롤러 역할을 하는 다른 클래스에 배치할 수 있습니다.이를 수행하려면 동일한 수신기를 가진 모든 명령을 추상화하는 방법인 명령어 패턴을 살펴볼 것을 권장합니다.주제넘게 나서 미안해

어쨌든 적절한 MVC 구현에서는 모델 -> 뷰 -> 컨트롤러 -> 뷰의 상호작용만 이루어집니다.

다른 상호 작용이 있을 수 있는 유일한 장소는 관찰자를 사용하여 보기를 업데이트하는 경우, 보기는 컨트롤러에 필요한 정보를 요청해야 합니다.

컨트롤러는 사용자 인터페이스 액션에서 어플리케이션레벨 액션으로 변환되는 것으로 알고 있습니다.예를 들어 비디오 게임에서 컨트롤러는 "마우스를 너무 많이 움직였다"를 "이러한 방향을 보고 싶다"로 변환할 수 있습니다.CRUD 앱에서는 번역이 "이것을 인쇄"하기 위해 "누군가 버튼 클릭"될 수 있지만 개념은 동일합니다.

따라서 델은 주로 사용자 주도의 입력/액션(뷰, 데이터 및 명백한 _모델을 제외한 다른 모든 것에 대해 _Logic)을 처리 및 대응하기 위해 컨트롤러를 사용합니다.

(1) (응답, 리액션 - 웹 앱이 사용자에게 응답하여 수행하는 작업) 블로그_컨트롤러

->main()

->handleSubmit_AddNewCustomer()

->verifyUser_HasProperAuth()

(2) ("business" logic, what and how the webapp "thinks") Blog_Logic

->sanityCheck_AddNewCustomer()

->handleUsernameChange()

->sendEmail_NotifyRequestedUpdate()

(3) (views, portals, how the webapp "appears") Blog_View

->genWelcome()

->genForm_AddNewBlogEntry()

->genPage_DataEntryForm()

(4) (data object only, acquired in _construct() of each Blog* class, used to keep all webapp/inmemory data together as one object) Blog_Meta

(5) (basic data layer, reads/writes to DBs) Blog_Model

->saveDataToMemcache()

->saveDataToMongo()

->saveDataToSql()

->loadData()

Sometimes we get a little confused on where to put a method, in the C or the L. But the Model is rock solid, crystal clear, and since all in-memory data resides in the _Meta, it's a no-brainer there, too. Our biggest leap forward was adopting the _Meta use, by the way, as this cleared out all the crud from the various _C, _L and _Model objects, made it all mentally easy to manage, plus, in one swoop, it gave us what's being called "Dependency Injection", or a way to pass around an entire environment along with all data (whose bonus is easy creation of "test" environment).

ReferenceURL : https://stackoverflow.com/questions/1015813/what-goes-into-the-controller-in-mvc