왜 모든 사람이 컨트롤러를 한 폴더에 넣고 다른 폴더에보기를합니까?

asp에서 mvc 프레임 워크, asp.net mvc 또는 nancy로 구부릴 준비가되었습니다. 어디를 가든 컨트롤러 / 모듈 용 폴더와보기 용 폴더가 표시됩니다. 이것은 유형별로 정리하는 것에 대한 파블로프의 반사 일까, 아니면 더 깊은 지혜가 작용하고 있는가? 함께 열 가능성이 높은 파일을 함께 저장하는 개념 증명 프로젝트가 약간 있습니다. 이 파일들도 서로를 호출 할 가능성이 높기 때문에 더 짧고 덜 부서지기 쉬운 상대 링크로 그렇게 할 수 있습니다. 이 패턴은 폴더 경로가 더 이상 자동으로 URL 경로에 대응하지 않으며, asp.net mvc에서는 프로젝트 템플릿 및 라우팅이 뷰의 \ 컨트롤러 / 스키마를 시행하기 때문에 mvc가 해결해야 할 문제입니다.

이 Microsoft 페이지 는 영역의 개념을 소개합니다. 이 인공적인 분리로 인해 다루기 힘든 큰 앱이 어떻게되는지를 인정하는 것으로 읽을 수 있습니다.

사람들은 "문제의 분리"에 반대 할 것이지만, 별도의 소스 파일을 가짐으로써 우려의 분리는 이미 이루어졌습니다. 단단히 결합 된 소스 파일을 가져 와서 폴더 구조의 반대쪽 끝으로 보내면 확실한 이점이 없습니다.

다른 사람이 싸우고 있습니까? 팁이 있습니까?

화물 컬트 프로그래밍 이라고 말하고 싶지만 이 구조에는 기술적 이유가 있습니다. Asp.Net MVC는 거의 모든 것에 대한 구성 방식에 대한 협약을 채택했습니다. 기본적으로 Razor보기 엔진 Views은 컨트롤러에서 리턴 할보기를 해결하기 위해 디렉토리를 검색합니다 . 그러나 다른 프로젝트 구조를 얻는 데 필요한 몇 가지 해킹 이 있으며 Microsoft 는보다 깔끔한 프로젝트 구조를 만들 수 있도록 Areas 라는 MVC 기능도 제공합니다 . 뷰 를 찾을 위치를 지정하기 위해 고유 한 뷰 엔진 을 구현할 수도 있습니다.

왜화물 컬트 프로그래밍이고 이것에 대해 옳다고 말합니까? Bob 아저씨 는 프로젝트의 디렉토리 구조가 MVC 응용 프로그램이라고 말해서는 안된다고 확신 했습니다. 그것은 그것이 가게 앞이거나 타임 오프 요청 시스템, 또는 무엇이든 말해줘야합니다. 높은 수준의 구조와 아키텍처 는 구현 방식 이 아니라이 기능이 무엇인지 알려 주어야합니다 .

요컨대, 나는 당신이 이것에 대해 옳다고 생각하지만 다른 디렉토리 구조는 단순히 프레임 워크와 싸우고 있으며 Asp.Net MVC 프레임 워크를 원래대로하지 않으려 고한다고 말하면 나를 믿어 라. 하도록 설계되지 않았습니다. 실제로 더 구성 할 수없는 것은 유감입니다.

아키텍처 문제를 신속하게 해결하기 위해 여전히 비즈니스 모델 (비즈니스가 아닌 비즈니스)과 DAL이 MVC 앱에서 호출되는 별도의 프로젝트 / 라이브러리에 있어야한다고 생각합니다.

컨트롤러가 실제로 뷰와 매우 밀접하게 결합되어 있으며 함께 수정 될 가능성이 있습니다. 우리는 의존성을 통한 결합과 논리적 결합의 차이점을 기억하는 것이 현명합니다. 코드에 의존성이 분리되어 있다고해서 논리적으로 덜 결합되지는 않습니다.

이유가 무엇이든 이것은 나쁜 실천입니다. 패키지 또는 폴더 (원하는 것이 무엇이든간에)는 상호 의존성이 약하기 때문에 매우 안티 OO입니다. 그 안에있는 클래스 (또는 파일)는 강한 상호 의존성을 가져야합니다.

한 폴더에있는 모든보기와 다른 폴더에있는 모든 컨트롤러를 던져 매우 밀접한 결합으로 두 개의 패키지를 만듭니다. 이것은 패키지 간 종속성이 약하다는 원칙에 위배됩니다.

뷰와 컨트롤러는 전체의 절반이며 서로 속해 있어야합니다. 왼쪽 양말에는 찬장 한 개와 오른쪽 양말에는 한 장의 끌기가 없습니다.

당신의 '왜 모두 ...?' 질문 : 여기에는 몇 가지 잠재적 인 이유가 있지만 실제로 주관적인 질문이기 때문에 어떤 조합이 실제 원인인지 확실하지는 않습니다.

• 폴더 및 네임 스페이스 구조가 일치하는 논리적 아키텍처 (모델, 뷰, 컨트롤러)를 복제하려면

• ASP.net MVC 프로젝트 템플릿을 따르는 규칙 및 편의성

• 네임 스페이스에 의해 그룹에, 이후 Controllers/폴더 A를 이끌 .Controllers네임 스페이스

• 수 DI / IOC의 몇 가지 시나리오를 가능하게 곳 컨트롤러 클래스 만 조회 된 / 스캔 '컨트롤러'로 끝을-/가 포함 된 네임 스페이스에서 (이 잘못 될 수 있음)

• T4 템플릿이 모델 및 컨트롤러를 스캔하고 스캐 폴딩하여 뷰를 생성 할 수 있도록

프로젝트에 적합한 경우 언제든지 자신 만의 컨벤션을 만들고 따를 수 있습니다. 아무도 당신을 막을 수 없습니다. 그러나 대규모 프로젝트 및 / 또는 대규모 팀에서 작업하는 경우 모든 사람에게 알려진 기본 규칙이 더 나은 선택 일 수 있습니다 (그러나 반드시 올바른 것은 아님).

컨벤션을 따르기가 더 쉽고 생산성을 방해하지 않는다면 반드시 그렇게하십시오! 블로그 커뮤니티에 개발자 커뮤니티와 정보를주고받을 수있는 블로그 게시물을 게시 할 수도 있습니다.

뷰와 컨트롤러를 별도의 디렉토리에 유지해야하는 한 가지 이유는 프로젝트에서 작업하는 프런트 엔드 및 백 엔드 개발자가있는 경우입니다. 프론트 엔드 개발자가 백엔드 코드에 액세스하지 못하게 할 수 있습니다 (예 : PCI 규정 준수를 지원하여 민감한 코드에 대한 액세스 권한을 가진 사람 제한).

또 다른 이유는 보기 경로를 약간 변경하여 "테마"를 쉽게 만들고 모든 템플릿을 전환하는 것 입니다.

세 번째 이유는 MVC 프레임 워크에서 뷰를 지정할 때 간단한 디렉토리 패턴을 갖기 때문입니다. 각 뷰에 대한 긴 경로보다 하위 디렉토리와 파일을 지정하는 것이 더 쉽습니다.

"꽉 조이는"유일한 방법은 다음과 같습니다.

1. 컨트롤러가 뷰로 보낸 변수.
2. 보기에서 양식 필드 또는 조치를 컨트롤러로 다시 보냅니다.

일반 컨트롤러를 사용하고 변수 이름을 일반 뷰에 유지하여 많은 뷰가 동일한 컨트롤러를 사용할 수 있고 많은 컨트롤러가 동일한 뷰를 사용할 수 있도록합니다. 이런 이유로 나는 견해를 완전히 분리하는 것을 선호합니다. 이 모델은 응용 프로그램에서 각 "사물"을 차별화 할 수있는 곳입니다. 속성 및 속성 목록을 사용하여 이러한 속성에 액세스 / 수정할 수 있습니다.

밀접하게 결합 된 코드의 경우, 패키지 또는 "모듈"의 일부인 모든 파일을 네임 스페이스 디렉토리에 보관하는 것이 효과적입니다. 그런 다음 스크립트를 사용하여 원시 템플리트를 기본 "views"디렉토리로 복사하거나 "컴파일"할 수 있습니다. 예를 들면 다음과 같습니다.

    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

불행하게도, 기존 테마의 구조를 변경하려면 패키지 디렉토리 안팎으로 더 많은 뷰를 업데이트하여보기를 업데이트하십시오.

뷰는 데이터가 json, xml, csv 또는 html인지 여부에 관계없이 데이터를 형식화하는 방법 일뿐입니다. 이것은 특히 응용 프로그램이 API로 작동하기를 원하는 경우에 도움이됩니다. 일반 변수 이름을 사용하여 데이터에서보기를 분리하려고하면 많은 컨트롤러 나 모델에 동일한 템플릿을 사용할 수 있습니다 (또는 유지해야하는 코드의 양을 최소화하기 위해 include를 사용).

반드시 모든 사람이 그렇게하는 것은 아닙니다. 예를 들어 python의 Django 프레임 워크는 앱의 개념을 가지고 있으며, 애플리케이션의 하위 모듈은 자체 모델과 뷰 및 템플릿을 사용하여 자체 디렉토리에 있습니다 (뷰는 본질적으로 Django가 컨트롤러를 호출하는 것입니다). "앱"을 쉽게 패키징하고 프로젝트 설정의 앱 목록에 포함시켜 프로젝트 전체에서 재사용 할 수 있기 때문에 일을하는 방식을 선호합니다. 또한 다른 부품이있는 곳을 찾는 것이 더 쉽습니다. urls.py 파일을보고와 같은 url(r'^users/', include('my_site.users.urls'))것을 보면 모듈 my_site.users에 사용자를 처리하는 모든 코드가 포함되어 있다는 것을 알고 있습니다. 나는 모듈을보고 알 my_site.users.views과 my_site.users.models나는 사용자가 생성 및 인증 방법을보고 싶을 때. 모든 경로가에 정의되어 있음을 알고 my_site.users.url있습니다.

또한 일반적인 경우에는 구성을 변경하거나 라이브러리로 패키지하고 OSS로 게시하여 다른 사이트에서 해당 모듈을 사용할 수 있습니다.

그것은의 기억 Microsoft는 방법으로 권장 많은 추천 구조를 따를 수 있도록, 서로 다른 폴더에있는 컨트롤러와 뷰를 유지하기를

1. 한 가지 이유는 컨트롤러가 항상 뷰와 일대일 관계를 갖지 않기 때문에, 특히 부분 뷰는 컨트롤러간에 공유 될 수 있습니다.
2. 또 다른 이유는 프로젝트가 커질 때 컨트롤러와 단위 테스트를 다른 프로젝트로 가져 오기를 원할 수도 있지만 뷰 / js / css가 서로 참조 할 때 뷰와 js / css가 함께 포함되어 있으면 동일한 작업을 수행하는 것이 매우 어렵습니다.

같은 사용자가 원하는 방식으로 일에 대해 많은 게시물이 있다는 것을 미루어 보아 이 .

기록을 위해

왜화물 컬트 프로그래밍이고 이것에 대해 옳다고 말합니까? Bob 아저씨는 프로젝트의 디렉토리 구조가 MVC 응용 프로그램이라고 말해서는 안된다고 확신했습니다. 그것은 그것이 가게 앞이거나 타임 오프 요청 시스템, 또는 무엇이든 말해줘야합니다. 높은 수준의 구조와 아키텍처는 구현 방식이 아니라이 기능이 무엇인지 알려 주어야합니다.

질문 : 누가 코드에 액세스 할 수 있습니까? 프로그래머. 최종 사용자는 코드에 관심이 있습니까? 그리고 프로그래머가하는 일은 코드입니다. 보다 구체적으로, 유형 (컨트롤러, 서비스, 모델 등)을 기반으로하는 클래스. 따라서 코드 동작 대신 코드 유형을 기반으로 코드를 찾을 수있는 경우 이치에 맞고 코드를 디버깅하기가 쉽습니다. 또한 팀 프로젝트, 하나는 컨트롤러, 다른 하나는 모델, 다른 하나는 dao 및 다른 하나는 뷰를 담당한다고 가정 해 봅시다. 프로젝트를 여러 부분으로 쉽게 분리 할 수 ​​있습니다. 좋은 코드는 구문 설탕 코드가 아니라 디버깅하기 쉬운 코드입니다. 밥 삼촌이 또 틀렸어

프로젝트 (상점)의 행동을 모방하려는 것은화물 컬트입니다.