source

WordPress MVC는 호환됩니까?

factcode 2023. 3. 20. 23:38
반응형

WordPress MVC는 호환됩니까?

어떤 사람들은 WordPress를 블로그 플랫폼으로 생각하고, 어떤 사람들은 CMS로 생각하고, 어떤 사람들은 WordPress를 개발 프레임워크라고 부른다.어느 쪽이든, 문제는 여전히 남아 있다.WordPress MVC는 호환됩니까?

포럼을 읽었는데 3년 전에 MVC에 대해 물어본 사람이 있어요.긍정적인 답변도 있었고 부정적인 답변도 있었다.MVC가 정확히 무엇인지 아무도 모르고 모두가 자신만의 방식으로 생각하고 있지만, 여전히 모든 논의에서 일반적인 개념이 존재합니다.

저는 MVC 프레임워크에 대한 경험이 거의 없고 프레임워크 자체에 대해서는 아무것도 없는 것 같습니다.MVC는 대부분 프로그래머가 하는 거 맞죠?WordPress로 돌아가서 코어 리라이트 엔진(WP_Rewrite)을 컨트롤러로 생각할 수 있을까요?쿼리 및 플러그인 로직을 모델로 사용하시겠습니까?테마를 전망으로?아니면 제가 다 틀렸나요?

감사합니다;)

워드프레스 자체는 MVC에서 설계되지 않았지만 프레임워크 내에서 매우 MVC 지향적인 주제와 플러그인을 구축할 수 있습니다.도움이 되는 몇 가지 툴이 있습니다.

WordPress MVC 솔루션:

WordPress.org의 MVC 스레드 아이디어 및 트레이스:

워드프레스는 일종의 소타 MVC죠어느 쪽인가 하면 풀 타입 MVC 레이아웃으로 View가 모델에서 데이터를 '풀'이것은 많은 다른 오브젝트를 사용하는 대신 매우 절차적인 방법으로 수행되지만 프런트 엔드 템플릿을 여러 가지 방법으로 쉽게 작성할 수 있습니다.

이것에 의해, 어느 정도의 컨트롤러 로직(즉, 일종의 소타 MVC)도 뷰에 표시됩니다.

Wordpress는 URL을 가져옵니다.워드프레스 코어는 컨트롤러 역할을 하며 데이터베이스의 초기 쿼리를 실행하고, 나아가 로드해야 할 뷰(카테고리 뷰, 싱글 투고 또는 페이지 뷰 등)를 결정합니다.그런 다음 INTIAL 쿼리 응답을 패키징하여 보기 파일로 보냅니다.

이 뷰 파일은 엄밀한 표시 전용 파일일 수도 있고 빌트인 파일 이외의 추가 정보/쿼리를 요구할 수도 있습니다.이는 컨트롤러의 데이터를 모델에서 뷰로 '푸시'하는 대신 뷰가 모델에서 데이터를 가져오는 MVC의 풀 유형입니다.

따라서 보기는 사이드바 또는 위젯 영역을 로드하는 코드를 볼 때 해당 정보를 요청합니다.그러나 컨트롤러는 사이드바에 어떤 위젯이 있는지 모델을 보고 현재 페이지에 표시되도록 설정된 위젯을 선택한 후 이를 보기로 반환합니다.

각각의 부분이 물체가 아니라고 해서 MVC가 줄어들지는 않습니다.테마를 변경하지 않고 WP 코어를 변경할 수 있습니다.마찬가지로 'get_pages()'와 같은 빌트인 함수를 사용하는 한 모델 및 데이터베이스 테이블은 함수가 올바른 데이터를 반환하는 한 변경될 수 있습니다.따라서 모델은 뷰와 독립적이며 컨트롤러도 독립적입니다(보통 코어보다 더 많은 작업을 수행하기 위해 뷰가 컨트롤러 로직을 추가하는 경우는 제외).

WPModel::get_pages('blah blah')와 같은 여러 가지 메서드와 것들을 포함하는 모델 오브젝트를 가질 수 있고, 모든 것을 그렇게 포함할 수 있지만, 여전히 근본적인 우려의 구분이 존재한다.

보기: template files Controller: WP core Model: 특정 데이터 처리를 처리하는 다양한 기능.

이름, 주장 등이 동일(또는 새로운 것이 추가됨)한 경우, 관심사 분리가 유지되고 다른 것을 방해하지 않고 한 가지를 변경할 수 있습니다.

MVC의 슈퍼 클린 버전은 아니지만(특히 훅이 관여하는 경우) 기본 레벨에서 시작합니다.

또, IMO라고 하는 것은 나쁜 것이 아닙니다.웹 사이트로부터의 요구는 본질적으로 절차적인 것입니다.이것은 시작과 끝이 명확하고, 요구를 처리하고, 데이터를 취득하고, 패키징하고, 다이를 실행하기 위한 절차만 필요합니다.이러한 스텝은 오브젝트 및 오브젝트 메서드 및 OOP 레이아웃을 사용하여 셋업할 수도 있고(일부 작업을 쉽게 할 수도 있습니다), 함수 호출의 많은 부분을 기입하여 분리할 수도 있습니다.개인 변수와 같은 클래스 구성원은 그렇게 손실되지만 응용 프로그램의 필요에 따라...신경 안 쓸 수도 있어

개발을 할 수 있는 유일한 방법은 없고 WP는 웹사이트의 20%에 위치하고 있기 때문에 제대로 하고 있다.복잡한 클래스 계층을 학습/기억하지 않아도 데이터베이스가 'x페이지의 하위 페이지'라는 질문에 답하고 해당 데이터를 처리할 수 있는 것과 관련이 있을 수 있습니다.OOP로 그렇게 쉽게 할 수 있을까요? 네, 하지만 Joomla가 OOP로 복잡한 커스텀 웹사이트를 구현하는 것이 얼마나 어려운지를 보여주는 예라면 WP는 훨씬 쉽고 빠르며 시간은 돈입니다.

코멘트에서 이미 언급했듯이 MVC는 특정 프레임워크가 아닌 아키텍처 설계 패턴이며, Wordpress는 MVC 패턴을 따르지 않습니다.

뷰(템플릿)는 프로그래밍 로직에서 분리되지만 프런트엔드에서만 분리되며 관리 패널에서는 분리되지 않으며 뷰와 애플리케이션 로직의 일반적인 분리가 반드시 MVC는 아닙니다.MVC 패턴의 구현은 보통 그 배후에 있는 일종의 객체 지향 프로그래밍 패러다임을 가정하고 워드프레스는 주로 절차적인 방법으로 구현되며, PHP 함수에 플레인 SQL 쿼리가 있기 때문에 실제 모델도 없습니다.

WordPress와 관련하여 정기적으로 논의되는 주제 중 하나는 WordPress와 MVC의 아이디어입니다.

하지만 중요한 것은 MVC가 웹 개발의 실탄이 아니라는 것입니다.네, 훌륭한 디자인 패턴입니다.개인적으로는 웹 어플리케이션 모델에 장갑처럼 맞는다고 생각합니다만, 모든 프레임워크나 플랫폼이 그러한 디자인 패턴을 구현하고 있는 것은 아닙니다.

적절한 예:WordPress는 MVC가 아닙니다.

그리고 그건 괜찮아.특히 워드프레스가 제공하는 패턴이 충분할 뿐만 아니라 올바르게 활용될 경우, 우리는 그것을 우리의 프로젝트에 끼워 넣으려는 욕구를 버려야 한다고 생각합니다.

"하지만 MVC는 좋아!"

저도요! 사실 저는 작년에 MVC 아키텍처를 어느 정도 모방한 프로젝트를 진행했습니다.MVC의 개략적인 예.

여기에 이미지 설명 입력

MVC의 개략적인 예.

예를 들어 다음과 같습니다.

Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.

마지막으로, 일련의 개서 규칙에 의해 어플리케이션은 /people/update/1 또는 /people/all 형식으로 예측 가능한 URL의 클린 세트를 얻을 수 있었습니다.Word Press는 어떤 패턴을 구현합니까?

WordPress는 이벤트 기반 아키텍처를 구현합니다(Overserver Pattern과 같은 여러 가지 변형).

즉, 개념적으로는 다음과 같이 생각할 수 있습니다.

Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.

무무복 ?? ??? 패턴의 인 예여기에 이미지 설명 입력 구동 인 예

당신이 원하는 방식으로 작동시키기보다는 그것이 작동하는 패러다임의 관점에서 생각하기 시작할 때, 그것은 자유롭다.그것은 문제를 훨씬 더 쉽게 해결하는데 도움이 된다.

결론은 다음과 같습니다.Word Press는 이벤트 주도형 디자인 패턴을 구현하기 때문에 MVC를 구현하려고 해도 훅 시스템을 활용해야 합니다.

조심하지 않으면 실제로 작업을 하지 않고 완벽한 아키텍처를 만들려고 할 수 있습니다.그러면 소프트웨어 분위기 속에서 건축 우주 비행사가 될 수 있습니다.디자인 패턴을 피한다는 말씀이신가요?

천만에!디자인 패턴은 무엇보다도 이전에 일반적으로 해결된 문제에 대한 해결책을 제공하기 때문에 목적에 도움이 됩니다.써!

하지만 제가 말하고자 하는 것은 우리가 패턴을 좋아한다고 해서 억지로 패턴에 맞추려고 할 필요는 없다는 것입니다.그건 그들의 목적이 아니야.대신 선택한 플랫폼에서 구현되는 주요 패턴(이 경우 이벤트 중심 패턴)을 활용하여 적합한 패턴(의존성 주입 등)을 구현합니다.

그렇지 않으면 장갑에 발을 담그려는 것과 같습니다.

커티시(및 완전 복사:P) : http://tommcfarlin.com/wordpress-and-mvc/ 에서 제공

검색 엔진에서 이를 히트하는 사용자를 위한 최신 정보로 업데이트하기 위해 wp-mvc 플러그인 http://wordpress.org/extend/plugins/wp-mvc/은 플러그인 개발을 위한 MVC 프레임워크를 만드는 데 큰 도움이 됩니다.자세한 것은, http://wpmvc.org/documentation/70/tutorial/ 를 참조해 주세요.

옵션 목록에 덧붙이자면, (저작자로서의 편견이 인정됩니다) swpMVC는 Rails, Sinatra, Express 및 FuelPHP에서 영감을 얻은 완전한 기능의 경량 MVC 프레임워크입니다.충분히 문서화되어 있고, wp-mvc를 사용하고 즐겼지만, 그 모델과의 상호작용을 위한 폼 컨트롤을 포함해 모델 스스로 뷰를 채울 수 있는 것을 원했습니다.

WordPress 위에 앱을 조립하는 데 필요한 컨트롤러 코드의 양을 줄이기 위해 이것을 조합했습니다.그 결과, WordPress 내부에서 동작하는 매우 빠르고 효과적인 프레임워크가 실현되었습니다.이 모델은 PHP Activerecord를 기반으로 하며 Post, PostMeta, User, UserMeta, Term 등을 포함한 기존 WordPress 데이터 유형에 8개의 모델이 포함되어 있습니다.액티브 레코드 라이브러리 덕분에 데이터 모델링이 매우 쉽고, 지금까지 이 프레임워크로 작업하는 것이 매우 즐거웠습니다.

또한 언더스코어 PHP 및 PHP Quick Profiler(Fuel PHP에서 볼 수 있음)와 함께 제공됩니다.

RockkoMVC는 WordPress 전용으로 구축된 마이크로 MVC 프레임워크입니다.이 프로젝트는 WordPress 응용 프로그램에서 AJAX 기능을 단순화할 뿐만 아니라 모델, 뷰 및 컨트롤러를 사용하는 다른 모든 이점을 테마에 맞게 제공하기 위한 것입니다.

최근 간단한 뷰 컨트롤러 시스템을 이용한 플러그인 작성을 시도했는데, 그 결과가 마음에 들어 템플릿의 내용을 자체 리포트로 분리했습니다.개체 기반 컨트롤러를 제공하여 변수를 PHP 템플릿, 템플릿 조각(템플릿 내의 템플릿) 및 구성 요소(자체 하위 컨트롤러가 있는 템플릿 조각)로 로컬로 전달합니다.모두 두 개의 작은 반으로 나누어져 있어요!

이 까지 WP 가 이 였습니다.;-).

MVC와는 거리가 멀고, MVC인지 아닌지는 사람들이 말하는 소르타 같은 건 없어.뷰 수준에서 논리를 쓴다고 해서 MVC 프레임워크로 인정되지는 않습니다.사람들이 그것을 사용하는 이유는 - 배우기 쉽고, 당신은 하드코어 php 프로그래머가 될 필요가 없다. 그들은 게으르기 때문이다.

언급URL : https://stackoverflow.com/questions/2857143/is-wordpress-mvc-compliant

반응형