느슨하게 결합 된 MVC 대신?

Question

저는 웹 프로그래머로 PHP 웍샵에서 일하고 있습니다. 대부분 우리는 좋은 코딩 방법을 사용하지만 사이트 전체에는 많은 구조를 사용하지 않습니다.

필자는 일부 실천 사례에 지루함을 느끼고 있으며, 나만을위한 것이 아니라 사무실의 하이브리드 프로그래머 웹 개발자에게 도움이되는 방법으로 몇 가지를 만들고 단순화하고 생성하려고합니다.

한 명의 직원이 PHP로 작성된 MVC 사이트를 남겨두고 약간 유지해야했지만 어떻게 작동합니까?하지만 불만 사항이 있습니다. 주요 불만 사항은 각 피스 의존성과 밀접하게 관련되어 있다는 것입니다 다른. 나는 우려의 분리의 이점을 본다. 그러나 이것은 누군가를 혼란스럽게 할 것이다. 그러나 나는 코드를보고있다.

예를 들어 사이트에 새 페이지를 추가해야하는 경우보기를 추가하고 모델을 추가 한 다음 컨트롤러를 업데이트해야합니다. 새로운 페이지를 만드는 특별 방법은이 방법보다 간단하며 프로그래머가 필요하지 않습니다.

나의 판단은 이것이 웹 사이트를 구축하는 것이 아니라 유지하는 것이 훨씬 더 나은 방법이라는 것입니다.

사이트의 여러 위치에 의존하지 않고도 코드를 효과적으로 재사용 할 수있는 디자인 패턴이 있다면 좋을 것입니다.

제 질문은 훨씬 느슨하게 결합 된 웹 사이트를 만들고 유지 관리하기위한 디자인 패턴이 있습니까? MVC에서 약간의 변형을 찾는 것이 아니라,보기에는 좀 다른 플러그인이 필요합니다.

편집 :

답변 주셔서 감사합니다! 다른 방법은 코드를 내 사무실에서 더 잘 수행하는 것입니다. Do I A) MVC를 위해 밀어 넣거나 B) 반 프로그래머에게 혼란스럽지 않게 대안을 찾고/구축하십시오. 우리는 이미 DB 연결 및 양식 지원과 같은 것에 클래스를 사용합니다. 이 질문의 요지는 B를 탐구하는 것이 었습니다.

Answer 1

X를 수행하는 데 필요한 모든 것이 하나의 파일 주위에 무작위로 흩어져 있기 때문에 코드가 혼란스럽고 혼란 스럽기 때문에 코드가 혼란 스럽습니다.

후자의 문제는 사람들을 모 놀리 식 모듈로 분리하는 "직관적 인"방법이 정확히 사람마다 다르다는 것입니다. 고도로 분해되고 인수 분해 된 코드는 머리를 감싸는 것이 거의 항상 어렵지만 일단 그렇게하면 유지 관리가 쉽게 수행됩니다. 나는 다른 누군가에게 혼란스러워 할지도 모른다고 생각하지만 저자는 그것을보고있다. MVC와 같은 대용량 패턴은 시간이 지남에 따라 그 주위에 구조화 된 프로젝트에서 더 쉽게 발견하고 작업 할 수 있기 때문에 사용됩니다.

MVC를 사용하는 또 다른 이점은 계층화를 고수하지 않으면 사용자를 후한 사람이 유지 관리하기가 더 어려워지지 않는다는 것입니다. 이는 이제 새로운 기능을 구현하는 데 필요한 부분을 미리 배치 할 수있는 곳이 있기 때문입니다.

엄격한 결합이 고려되는 한 실제로 레이어를 연결하지 않고도 기능을 구현할 수는 없습니다. 느슨한 결합은 레이어가 서로 무지하다는 것을 의미하지는 않습니다. 즉, 레이어가 다른 레이어가 구현되는 방식을 인식하지 못한다는 의미입니다. 예 : 컨트롤러 레이어는 SQL 데이터베이스를 사용하고 있는지 또는 데이터 액세스 레이어에서 데이터를 유지하기 위해 이진 파일을 쓰는지 상관하지 않습니다. 단지 모델 개체를 가져 와서 저장할 수있는 데이터 액세스 레이어가 있습니다.또한 뷰 레이어에서 PHP 또는 Smarty를 사용할지 여부에 상관없이 미리 정의 된 이름으로 일부 객체를 사용할 수 있도록해야합니다. 뷰 레이어는 컨트롤러 레이어가 있다는 것을 알 필요조차 없습니다. -/something /에 의해 제공되는 위에서 언급 한 이름 아래에 준비된 데이터가 표시되도록 호출됩니다.

Answer 2

나는 당신이 이미 어쨌든 템플릿을 사용하고 있기 때문에 MVC에 대한 귀하의 문제를 실제로 보지 못했다고 말할 수 밖에 없습니다. 저는 이것을 응용 프로그램에 구조를 추가하려고 할 때 자연스럽게 전개되는 패턴으로 생각합니다.

사람들이 처음으로 PHP 응용 프로그램을 개발하기 시작하면 코드는 대개 하나의 큰 혼란입니다. 프리젠 테이션 논리는 데이터베이스 논리와 혼합 된 비즈니스 논리와 혼합됩니다. 사람들이 일반적으로 취하는 다음 단계는 일종의 템플릿 방식을 사용하는 것입니다. 여기에 smarty와 같은 특수한 템플릿 언어가 포함되는지 또는 프리젠 테이션 마크 업을 별도의 파일로 분리하는지는 중요하지 않습니다.

이 후 우리 대부분은 데이터베이스 액세스 논리에 전용 함수 나 클래스를 사용하는 것이 좋습니다. 이것은 실제로 실행되는 각 쿼리에 대한 특수 함수를 작성하고 모든 함수를 공통 include 파일에 배치하는 것보다 더 고급 일 필요가 없습니다.

이 모든 것이 나에게 매우 자연스러운 것처럼 보이며, 나는 그것이 매우 논란의 여지가 없다고 생각합니다. 그러나이 시점에서 기본적으로 이미 MVC 방식을 사용하고 있습니다. 이 외의 모든 것은 일반적으로 사용되는 코드를 다시 작성해야 할 필요성을 제거하기위한 다소 복잡한 시도입니다.

나는 이것이 당신이 듣고 싶지 않을 수도 있지만, MVC를 재평가해야한다고 생각합니다. 무수히 많은 수의 구현이 존재하며, 그 중 어느 것도 자신의 필요에 맞지 않는 경우라면, 당신은 언제나 자신 만의 기본적인 구현을 작성할 수 있습니다.

이 방법을 살펴보십시오. 이미 템플릿 언어를 사용하고 있으므로 일반적으로 처음에는 일반 PHP 파일을 만들고 새 페이지를 만들 때마다 templare 파일을 만들어야합니다. MVC는 이것보다 더 발전 할 필요는 없으며 대부분의 경우 MVC가 그렇지 않습니다. 데이터 액세스를 처리하고 현재 시스템에 추가하는 더 정교한 접근법을 조사하는 것이 실제로 필요한 것일 수도 있습니다.

Answer 3

프레임 워크 템플릿을 살펴보면 MVC 패턴이 응용 프로그램을 작성하는 데있어 "느슨하게 결합 된"방법 중 하나라는 것을 알았습니다.

응용 프로그램의 부분 간 인터페이스 또는 계약과 같은 관계를 생각해보십시오. 모델은이 데이터를 뷰와 컨트롤러에서 사용할 수 있도록합니다. 아무도 정확하게 신경 쓰지 않습니다 모델은 그렇게합니다. ActiveResource와 같은 외부 데이터 소스에서 MySQL과 같은 일반적인 DBMS를 플랫 파일에서 읽고 쓸 수 있습니다. 단, 거래가 끝나면 가능합니다.

컨트롤러는 특정 데이터를보기에서 사용할 수 있도록하고 모델을 사용하여 약속을 이행합니다. 보기가 걱정하지 않습니다 컨트롤러가 어떻게합니까.

보기에서는 모델과 컨트롤러가 약속을 지키고 진공 상태로 개발 될 수 있다고 가정합니다. 모델과 컨트롤러는 뷰가 XML, XHTML, JSON, YAML, plaintext 등을 생성하는지 상관하지 않습니다. 계약 종료 시점을 지키고 있습니다.

물론 뷰와 컨트롤러는 어떤 것이 존재한다는 것에 동의해야합니다. 해당 Controller 활동이없는보기는 정상적으로 작동하지만 절대로 사용할 수 없습니다.

<?php 
class StaticController extends ApplicationController 
{ 

    /** 
    * Displays our "about" page. 
    */ 
    public function about() 
    { 
     $this->title = 'About Our Organization'; 
    } 
} 

그런 다음 관련보기 정적 인 텍스트를 포함 할 수 있습니다 : 정적 페이지의 경우 수도로 컨트롤러 는 아무것도하지 않는 경우에도 마찬가지입니다. (예, 전에 이와 같은 것을 구현했습니다. 정적 뷰를 다른 사람에게 넘겨주고 "그냥 이것을 써주세요"라고 말하면 좋을 것입니다.)

M, V 및 C 사이의 관계를 계약 또는 인터페이스에서 MVC는 갑자기 매우 느슨하게 결합 된 것처럼 보입니다. 독립 실행 형 PHP 파일의 유혹에주의하십시오. 6 개의 .inc 파일을 포함하고 필요로하거나 응용 프로그램 로직을 디스플레이 (일반적으로 HTML)와 혼합하기 시작하면 개별 페이지를 좀 더 느슨하게 결합 할 수 있지만 중요한 측면을 혼란스럽게 만듭니다.

"profile.php"와 "index.php"는 완전히 관련이 없지만 비용은 어느 정도입니까?

편집 : 편집에 대한 응답으로 : Push for MVC. 당신은 "하프 프로그래머"라고 말했고, HTML과 CSS를 잘 사용하지만 프런트 엔드 사용자는 서버 측에서도 프로그래밍 경험이없는 사람이 있습니까? MVC 프레임 워크를 사용하면 뷰를 전달하고 "이 부분에 대한 작업"이라고 말할 수 있습니다.

Answer 4

새 페이지가 필요할 때 새로운 모델 및 컨트롤러 액션을 만들어야한다는 사실은 M, V 및 C 레이어가 밀접하게 결합되었다고 생각하지 않습니다. 이것은 단지 관심사의 분리이며 분리 된 시스템에 기여합니다.

즉, MVC의 의도를 왕실에서 망칠 수 있습니다. (그리고 저는이 같은 응용 프로그램에서 작업했습니다) 구성 요소가 밀접하게 결합되도록 만듭니다. 예를 들어 사이트에서 '렌더링 엔진'을 컨트롤러 레이어에 직접 배치 할 수 있습니다. 이것은 분명히 더 많은 결합을 추가 할 것입니다. 대신 컨트롤러가 사용할 뷰의 이름 만 인식하고 그 이름을 별도의 렌더링 엔진에 전달할 수 있도록 올바른 MVC가 설계됩니다.

MVC의 잘못된 디자인의 또 다른 예는 뷰에 하드 코딩 된 URL이있는 경우입니다. 이것이 라우팅 엔진의 역할입니다. 보기는 호출되어야하는 조치와 조치에 필요한 매개 변수만을 인식해야합니다. 그런 다음 라우팅 엔진이 올바른 URL을 제공합니다.

Answer 5

젠드 프레임 워크는 매우 느슨하게 결합되어 매우 좋습니다. 그것을 체크 아웃 :

http://framework.zend.com

이 문서는 너무 유용 할 수 있습니다

http://blog.fedecarg.com/2009/02/22/zend-framework-the-cost-of-flexibility-is-complexity/

Answer 6

당신은 코드 점화를 시도 할 수 있습니다. 매우 배우기 쉽고 엄격하게 MVC를 채택하지 않지만 코드 구조가 좋습니다.

Answer 7

코드 Igniter와 Kohana (CI 자손)는 괜찮 으면서도 느슨하게 MVC입니다. 나는 simple php framework을 좋아한다. 그것은 당신의 방식으로는 얻지 못하며, 구조 나 복잡한 관습을 강요하지 않으면 서 중요한 것들을 제공합니다.

Answer 8

아 ... 좋은 오래된 MVC 인수.

"MVC"스타일로 작성된 다중면 PHP 응용 프로그램을 유지해야하지만 전부는 아닙니다. 더욱이 각기 다른 부분에는 MVC를 수행하는 다양한 방법이 있습니다. 모두 MVC입니다. 그리고 일부 페이지는 모두 스스로 처리합니다.

주요 문제는 프레임 워크 코드에 다양성이 있다는 것이 아니라 코드 작성자가 이 아니고이 API를 추상화하는 방법을 분명히 이해했음을 의미합니다. IMO, ths는 MVC 프레임 워크에서 가장 큰 문제입니다. 내가 작업해야하는 거의 모든 코드는 "모델"을 함수를 넣는 장소로 사용합니다. 유지하기 위해 악몽입니다.

• 검색하고 영구 저장소를 저장하고 아주 작은 후 보이는 API 경계하는의 독특하고 잘 정의 된 데이터 액세스 레이어 :

  는 몇 가지가 필요 IME이 유지 보수를 만들려면 .

  "모델"이라는 용어는 논쟁의 여지가 있기 때문에 사용하지 않습니다. 그 계층이 데이터 저장 방법을 신경 써서는 안되는 것이 무엇이든 데이터베이스 핸들과 같은 것에 대해서는 걱정할 필요가 없습니다. 즉, 모두 데이터 액세스 계층의 작업입니다.

• Dispatcher는 매우 가벼우 며 발송 만하지 않는 마술을하지 않습니다.

지금 당신은 아마 정규화 오류가 디스패처에서 확인 요청 및 매개 변수를 받아들이는 것이 필요합니다 (일반적으로 개체로) 데이터를 가져 오는 한 곳에서 다른 모든 것들을 넣을 수 있습니다, 그것은 할 필요가 변경합니다, 필요로하는 데이터를 저장하고 데이터를보기 위해 표시해야합니다. 이 단계에서 작업을 통해 200 줄의 코드를 실행하면이 작동합니다. 다른 곳에서 호출 된 다른 파일의 함수로 비트를 hive 할 필요가 없습니다. 이 파일의 끝 부분에보기를 배치 할 수도 있습니다! 이상주의는 열망하는 것이 좋지만 실용주의는 봐야한다. 이것은 유지 보수 가능하다..

는 프레임 워크를 적용의

PHP의 부족이 가장 좋은 프레임 워크는 PHP가 무엇을 할 수 있음을 의미합니다 (좋아, ... 이상 호언 장담) : 그들은 비켜있어. 일부 유지 보수가 가능한 코드 중 맨 위에 단일 require() 문이 있었고 데이터 객체 (SQL이 보이지 않음)로 모든 데이터 조작이 수행 된 후 서식 파일 기능으로 둘러싸인 HTML이 출력되고 양식 컨트롤은 일관된 함수 API.