최근에 나는 Logic-less 템플릿 이라고 주장하는 콧수염 을 만났습니다 .
그러나 왜 그것이 Logic-less 방식으로 설계되었는지에 대한 설명은 없습니다. 즉, 논리없는 템플릿의 장점은 무엇입니까?
답변
즉, 발에 총을 쏘는 것을 방지합니다. 예전 JSP 시대에는 JSP 파일에 Java 코드가 뿌려진 것이 매우 일반적이었으며 코드가 흩어져 있기 때문에 리팩토링이 훨씬 더 어려워졌습니다.
콧수염처럼 디자인 에 따라 템플릿의 로직을 방지 하면 로직을 다른 곳에 배치해야하므로 템플릿이 깔끔하게 정리됩니다.
또 다른 장점은 관심사 분리 측면에서 생각해야한다는 것입니다. 컨트롤러 또는 논리 코드는 데이터를 UI로 보내기 전에 데이터 마사지 를 수행해야합니다 . 나중에 템플릿을 다른 템플릿으로 전환하면 (다른 템플릿 엔진을 사용하기 시작한다고 가정 해 보겠습니다) UI 세부 정보 만 구현해야했기 때문에 전환이 쉬울 것입니다 (템플릿에 논리가 없기 때문에).
답변
나는 거의 외롭다는 느낌이 들지만, 나는 확실히 반대 진영에있다. 템플릿에서 비즈니스 로직을 혼합 할 수있는 가능성이 프로그래밍 언어의 모든 기능을 사용하지 않는 충분한 이유라고 생각하지 않습니다.
논리없는 템플릿에 대한 일반적인 주장은 프로그래밍 언어에 대한 전체 액세스 권한이있는 경우 템플릿에없는 논리를 혼합 할 수 있다는 것입니다. 칼을 사용하면자를 수 있기 때문에 숟가락으로 고기를 썰어 야한다는 추론과 비슷합니다. 이것은 매우 사실이지만 신중하게 사용하더라도 후자를 사용하면 훨씬 더 생산적이 될 것입니다.
예를 들어 콧수염을 사용하는 다음 템플릿 스 니펫을 고려하세요 .
{{name}}:
<ul>
{{#items}}
<li>{{.}}</li>
{{/items}}
</ul>
나는 이것을 이해할 수 있지만 다음 ( 밑줄 사용 )이 훨씬 더 간단하고 직접적이라는 것을 알았습니다.
<%- name %>:
<ul>
<% _.each(items, function(i){ %>
<li><%- i %></li>
<% }); %>
</ul>
즉, 논리없는 템플릿이 장점이 있다는 것을 이해합니다 (예 : 변경없이 여러 프로그래밍 언어에서 사용할 수 있음). 저는 이러한 다른 장점이 매우 중요하다고 생각합니다. 나는 그들의 논리없는 성격이 그들 중 하나라고 생각하지 않습니다.
답변
콧수염은 논리가 없습니까?
그렇지 않나요?
{{#x}}
foo
{{/x}}
{{^x}}
bar
{{/x}}
이것과 꽤 비슷합니까?
if x
"foo"
else
"bar"
end
그리고 그것은 프리젠 테이션 로직과 꽤 비슷 하지 않습니까?
답변
논리없는 템플릿은 채우는 방법이 아닌 채울 구멍이 포함 된 템플릿입니다. 논리는 다른 곳에 배치되고 템플릿에 직접 매핑됩니다. 이러한 우려의 분리는 이상적입니다. 템플릿은 다른 논리 또는 다른 프로그래밍 언어로 쉽게 빌드 할 수 있기 때문입니다.
로부터 수염 설명서 :
if 문, else 절 또는 for 루프가 없기 때문에 “논리없는”이라고 부릅니다. 대신 태그 만 있습니다. 일부 태그는 값으로 대체되고 일부는 아무것도 표시되지 않고 다른 태그는 일련의 값으로 대체됩니다. 이 문서에서는 다양한 유형의 Mustache 태그에 대해 설명합니다.
답변
동전의 뒷면은 비즈니스 로직을 프레젠테이션에서 제외시키려는 필사적으로 시도하면 모델에 많은 프레젠테이션 로직을 넣게된다는 것입니다. 일반적인 예는 테이블의 교대 행에 “홀수”및 “짝수”클래스를 배치하려는 경우 일 수 있습니다. 이는 뷰 템플릿에서 간단한 모듈로 연산자로 수행 할 수 있습니다. 그러나 뷰 템플릿이 그렇게 할 수 없다면 모델 데이터에 어떤 행이 홀수 또는 짝수인지 저장해야 할뿐만 아니라 템플릿 엔진이 얼마나 제한되어 있는지에 따라 모델을 오염시켜야 할 수도 있습니다. 실제 CSS 클래스의 이름으로. 뷰는 모델과 완전히 분리되어야합니다. 그러나 모델은 뷰에 구애받지 않아야하며, 이러한 “논 로직”템플릿 엔진 중 많은 부분이이를 잊어 버리게 만듭니다. 논리는 두 곳 모두에 있습니다.실제로 어디로 가는지 정확하게 결정합니다. 프레젠테이션 문제입니까, 아니면 비즈니스 / 데이터 문제입니까? 100 % 깨끗한 시각을 갖기위한 노력의 일환으로, 오염은 눈에 잘 띄지 않지만 똑같이 부적절한 곳으로 떨어집니다.
다른 방향으로 되돌아가는 움직임이 증가하고 있으며, 상황이 더 합리적인 중간 지점의 어딘가에 집중되기를 바랍니다.
답변
그것은 당신의 템플릿을 더 깨끗하게 만들고, 그것은 당신이 적절하게 단위 테스트를 할 수있는 곳에 로직을 유지하도록 강요합니다.
답변
이 대화는 중년의 승려들이 핀 끝에 얼마나 많은 천사가 들어갈 수 있는지에 대해 토론 할 때처럼 느껴집니다. 즉, 종교적이고 쓸데없고 잘못 집중된 느낌이 들기 시작했습니다.
사소한 폭언이 계속됩니다 (무시해도됩니다) :
계속 읽고 싶지 않다면 .. 위의 주제에 대한 저의 짧은 대답은 다음과 같습니다. 논리없는 템플릿에 동의하지 않습니다. 나는 그것을 극단주의의 프로그래밍 형태라고 생각합니다. 🙂 🙂
이제 내 폭언이 본격적으로 계속됩니다. 🙂
많은 아이디어를 극단적으로 취하면 결과가 우스꽝스러워 진다고 생각합니다. 그리고 때때로 (즉이 주제) 문제는 우리가 “잘못된”아이디어를 극단으로 가져가는 것입니다.
보기에서 모든 논리를 제거하는 것은 “우스꽝스럽고”잘못된 생각입니다.
잠시 뒤로 물러서십시오.
우리가 스스로에게 물어봐야 할 질문은 왜 논리를 제거 하는가? 개념은 분명 관심사 분리입니다 . 가능한 한 비즈니스 로직과 별도로 뷰 처리를 유지하십시오. 왜 이러나요? 이를 통해 뷰 (다른 플랫폼 : 모바일, 브라우저, 데스크톱 등)를 교체 할 수 있으며 제어 흐름, 페이지 시퀀스, 유효성 검사 변경, 모델 변경, 보안 액세스 등을보다 쉽게 교체 할 수 있습니다. 보기 (특히 웹보기)에서 제거하면보기를 훨씬 더 읽기 쉽고 유지 관리하기 쉽습니다. 나는 그것을 얻고 그것에 동의합니다.
그러나 우선 순위는 관심사 분리에 있어야합니다. 100 % 논리없는보기가 아닙니다. 뷰 내의 논리는 “모델”을 렌더링하는 방법과 관련되어야합니다. 제가 아는 한, 뷰의 논리는 완벽합니다. 비즈니스 로직이 아닌 뷰 로직을 가질 수 있습니다.
예, 코드 로직과 뷰 로직을 거의 또는 전혀 분리하지 않고 JSP, PHP 또는 ASP 페이지를 작성했을 때 이러한 웹 앱의 유지 관리는 절대적으로 악몽이었습니다. 저를 믿으세요. 저는이 괴물들 중 일부를 만들고 유지했습니다. 유지 보수 단계에서 나와 동료 방식의 오류를 실제로 (내장 적으로) 이해했습니다. 🙂 🙂
따라서 높은 (업계 전문가)의 칙령은 프론트 뷰 컨트롤러 (핸들러 또는 액션 [웹 프레임 워크 선택]에 전달되는)와 같은 것을 사용하여 웹 앱을 구성해야하며 뷰에는 코드가 없어야합니다. . 뷰는 멍청한 템플릿이되었습니다.
그래서 저는 일반적으로 위의 정서에 동의합니다. 칙령 항목의 세부 사항이 아니라 칙령 뒤에있는 동기, 즉 관점과 비즈니스 논리 사이의 관심사를 분리하려는 욕구입니다.
제가 참여한 한 프로젝트에서 우리는 논리없는 관점의 아이디어를 터무니없는 극단까지 따르려고했습니다. 모델 객체를 html로 렌더링 할 수있는 자체 개발 템플릿 엔진이있었습니다. 단순한 토큰 기반 시스템이었습니다. 아주 간단한 이유 때문에 끔찍했습니다. 때로는 뷰에서이 HTML 스 니펫을 표시할지 여부를 결정해야합니다. 결정은 일반적으로 모델의 일부 값을 기반으로합니다. 뷰에 논리가 전혀없는 경우 어떻게합니까? 글쎄 당신은 할 수 없습니다. 나는 이것에 대해 우리 건축가와 몇 가지 중요한 논쟁을했다. 우리의 뷰를 작성하는 프론트 엔드 HTML 사람들은 이것에 직면했을 때 완전히 방해를 받았으며 다른 단순한 목표를 달성 할 수 없었기 때문에 매우 스트레스를 받았습니다. 그래서 템플릿 엔진에 간단한 IF 문 개념을 도입했습니다. 나는 당신에게 그에 따른 안도감과 평온함을 설명 할 수 없습니다. 템플릿의 간단한 IF- 문 개념으로 문제가 해결되었습니다! 갑자기 템플릿 엔진이 좋아졌습니다.
그렇다면 우리는 어떻게이 어리석은 스트레스 상황에 빠졌을까요? 우리는 잘못된 목표에 집중했습니다. 우리는 규칙을 따랐습니다. 당신의 견해에 논리가 없어야합니다. 그건 틀렸어요. 나는 “경험의 법칙”이 당신의 견해에서 논리의 양을 최소화해야한다고 생각한다. 그렇지 않으면 실수로 비즈니스 로직이 뷰에 포함되도록 허용 할 수 있으므로 우려 사항 분리를 위반합니다.
“뷰에 논리가 없어야합니다”라고 선언하면 “좋은”프로그래머인지 쉽게 알 수 있습니다. (그게 당신의 선량 척도라면). 이제 위의 규칙을 사용하여 중간 정도의 복잡한 웹 앱을 구현해보십시오. 그렇게 쉽게 할 수는 없습니다.
나에게있어서 논리의 규칙은 그렇게 명확하지 않으며 솔직히 그것이 내가 원하는 곳이다.
뷰에서 많은 논리를 볼 때 코드 냄새를 감지하고 뷰에서 대부분의 논리를 제거하려고합니다. 비즈니스 논리가 다른 곳에 있는지 확인하려고합니다. 우려 사항을 분리하려고합니다. 하지만 제가 보기에서 모든 논리를 제거 해야 한다고 말하는 사람들과 대화를 시작하면 , 제가 위에서 설명한 것과 같은 상황에서 끝날 수 있다는 것을 알고있는 것처럼 광신주의에 불과합니다.
나는 내 폭언을 끝냈다. 🙂
건배,
데이비드
