MVC를 배우고 새로운 것을 배우고 있습니다. MVC에 대한 기사를 읽었습니다. 내가 이해할 수 무엇asp.net MVC 프레임 워크?
했다 :
보기 결코 직접 모델 통신 다만 프론트 엔드입니다. 그것은 항상 Controler를 사용합니다.
컨트롤러는 모델보기 및 통신에 응답하고 이에 응답하는 소프트웨어 구성 요소입니다.
모델은 모든 프로그래밍 로직, 검증, 데이터베이스 통신, 서비스 등 나의 이해는 올바른
가있을 것이다?
곳 마시고 수업을 통해 모델에있을 것입니다 :
나는 더 배우고 싶은?
모든 검증, db 통신 코드 및 비즈니스 로직이있을 경우 복잡한 모델이되지 않습니까?
모델에 muplitle 클래스/라이브러리가있을 경우 직접 제어 할 수 있습니다. 그들은 다시 Controler에 응답하고 컨트롤은 다시 View와 통신 할 것입니다.
감사와 도움에 감사드립니다.
보기를 템플릿으로 생각할 수 있습니다. 보기의 데이터는보기에서 지정하는 스폿에 채워집니다. 보기는 입력 템플리트가 될 수도 있습니다. 입력 템플리트는 입력에 사용되는 필드를 지정하고 해당 필드가 제어기로 전송되도록합니다.
컨트롤러가 대부분의 노력을합니다. 모든 웹 요청은 컨트롤러를 통과합니다. 컨트롤러는 뷰와 모델 사이의 조정자 역할을합니다. 컨트롤러는 모델을 뷰에 전달하고 뷰는 모델을 가져 와서 데이터를 사용하여 필드를 채 웁니다.
모델은 데이터 모델을 정의하는 일련의 데이터 개체입니다. 때로는 이러한 기능이 특별한 기능이없는 독립 실행 형 클래스 일 때가 있으며, 때로는 Entity Framework와 같은 도구에서 생성 된 클래스가됩니다.
MVC는 사용자 인터페이스를 별도의 구성 요소로 분리하여 유지 관리하기 쉽게 설계된 프레임 워크입니다.
그냥 기본 :
모델 :이 데이터베이스에 저장하고 필요할 때 검색 할 것입니다 평범한 구식의 C# 클래스 (POCO) 일 것이다. 내 의견으로는 여기에 논리가 없으면 최소한이어야한다. IMHO와 같은 데이터베이스 연결 설정은 컨트롤러에서 처리해야합니다.
보기 : 렌더링 된 HTML 페이지는 데이터베이스 (POCO)에서 검색 한 데이터를 기반으로합니까? 여기서 프레젠테이션을위한 모든 논리를 갖게됩니다. 예 : 마스터 페이지 사용. PartialView의 삽입.
컨트롤러 : 여기에 비즈니스 로직이 있습니다. 이는 요청을 처리하여 뷰 (ViewModels)에 대해 모델을 설정하는 것을 의미합니다.
개발하는 동안/개발하는 동안 단순화/명확화하는 것 사이의 추상화입니다. 그러나 종종 회색 선이 생깁니다.
다음은 Facebook에서 사용자 프로필을 렌더링하는 방법에 대한 간단한 예입니다. 먼저 주어진 사용자에 대한 요청이 서버에 의해 적절한 컨트롤러에 전달됩니다. 컨트롤러는 요청을 받아서 어떤 사용자의 정보가 요청인지 파악하고, 데이터베이스에서 사용자 데이터를 연결 및 검색하고, 데이터/모델을 적절히 포맷하고,보기로 전달합니다. 그런 다음 뷰는 렌더링 된 다음 모델에서 데이터를 간단히 추출하여 뷰에 렌더링합니다.
보기는 모델과 직접 통신하지 않는 프런트 엔드입니다. 그것은 항상 Controler를 사용합니다.
보기가 프런트 엔드입니다. 예. 모델을 모델로 변경하면 안되지만 모델에서 정보를 얻어야하므로 모델을 알아야합니다. 컨트롤러로부터 모델을 받으면 링크/폼을 통해 컨트롤러와 '상호 작용'합니다.
컨트롤러는 모델보기 및 통신에 응답하고 응답 할 소프트웨어 구성 요소입니다.
컨트롤러는보기를 '수신하지 못하지만보기에서 온 요청 (자체보기 중 하나 일 필요는 없음)을 수신합니다. 따라서 요청에 응답합니다. 조회 자체가 아닙니다. Model을 가져오고, Request를 기반으로 모델을 변경하기 위해 Model 메소드를 호출하는 것을 처리해야합니다 ("모델과 통신"). 그런 다음 모델을 뷰로 가져와 표시합니다.
모델은 모델에 있지 않을 수 있습니다 종종 모든 프로그래밍 로직, 검증, 데이터베이스 통신, 서비스 등
로직과 서비스를 제공합니다. 서비스는 분리되어 있어야하며 ("M.V.C."중 하나가 아님) 일반적으로 컨트롤러는 응용 프로그램 별 논리가 포함되어 있습니다. 유효성 검사 이 모델에 정의되어있을 수도 있지만 (일부 순수 주의자는이를 원하지 않습니다) 표시로 표시가보기에서 수행됩니다. 데이터베이스 통신은 모델에 있거나,이를 수행하는 서비스가있을 수 있습니다.
모델의 POCO 등급은 어디입니까?
POCO 클래스는 모델에 있습니다. 그렇습니다. 따라서 ViewModel 클래스 (종종 POCO 클래스 자체)가됩니다. 모델에는 사용하는 장소가 다르므로 같은 데이터를 나타내는 여러 가지 방법을 포함하여 상황에 따라 데이터를 나타내는 많은 클래스가있을 수 있습니다.
예 : 사용자 개체 속성 중 일부를 나타내며 "사용자 프로필 표시"모델과 완전히 다른 "암호 변경 모델"이있을 수 있습니다.
데이터베이스 항목을 직접 나타내는 Model 객체는 자체 라이브러리에있을 수 있지만 ViewModel 객체는 별도의 라이브러리에있을 수 있습니다. 모델은 컨트롤러 또는 뷰를 인식하지 않아야합니다. View에서 염두에 두는 ViewModel 객체 (View에 필요한 속성 만 포함)를 만들지 만 ViewModel 자체에는 Views와 연결된 코드가 없어야합니다.
감사합니다. @Mystere Man, 귀하의 설명에서 나는 View에 대해 매우 분명합니다. 컨트롤러가 뷰와 모델을 조정합니다.그러나 그것들 사이의 채널일까요? 또는 어떤 논리도 가질 것입니다. 양식 검증, manuplation, 데이터베이스 운영 코드는 어디에 있을까요? 모델 또는 컨트롤러에서? – haansi
@haansi - 컨트롤러에는 로직이 가능한 한 적어야합니다. 일반적으로 비즈니스 논리를 수행하기 위해 일련의 서비스로 비즈니스 로직을 넘겨 주면 컨트롤러에서 호출하게됩니다. MVC의 유효성 검사는 일반적으로 모델에서 정의되지만 프레임 워크에서 처리됩니다. 컨트롤러의 유효성 검사가 실패한 경우에만 응답합니다. 데이터베이스 작업은 일반적으로 서비스 및/또는 리포지토리에 저장되며 다시 컨트롤러에서 호출되어 모델을 채 웁니다. –
고맙습니다. 서비스에 db 로직이 있고 이러한 서비스가 컨트롤러에 의해 호출 될 것이라고했습니다. 내 무지 때문에 유감 스럽지만 서비스 모델이라고 부르지 않는다는 것은 무엇을 의미합니까? 다른 구성 요소가있을 것이고 컨트롤러가 모두 호출 할 수 있습니까? 서비스는 그 중 하나 일뿐입니다. 죄송합니다. 다시 모델에서 혼동합니다. 프런트 엔드가 분리되면 어떤 모델이 될 것입니다. 비즈니스 로직인가요? 우리는 db 로직을 db 로직의 일부로 부르지 않을 것인가? Plz 가이드. – haansi