Sitecore를 배우는 동안 웹의 Sitecore 샘플 코드의 대부분이 .NET 대신 XSL에 있음을 발견했습니다.C# 대신 Sitecore에서 XSL을 사용하면 어떤 이점이 있습니까?
.NET 개발자로서 익숙해 진 프로세스보다 XSL을 선택하면 어떤 이점이 있습니까?
XSL을 사용하면 처리 속도면에서 이점이 있습니까?
구문에 익숙해지면 실제로 XSL을 쉽게 사용할 수 있습니까?
:-) 내 모든 Sitecore 개발 자신의 훨씬 넘는 95 %를위한 .NET을 사용하여 외부 "라이브러리"또는 XSLT에서 사용할 수있는 C#으로 메서드를 개발할 때 극복해야 할 XSLT의 많은 한계가 있습니다.
그래서 Asp.Net을 더 간단하게 사용합니다. 하지만 Asp.Net은 XSLT보다 훨씬 낫습니다.
하지만 XSLT는 좋은 일이 있습니다
처음 Sitecore로 작업을 시작했을 때 회사에서 XSLT를 많이 사용했지만 그 한계로 인해 서서히 벗어났습니다. 그리고 여기에있는 대부분의 사람들이 Asp.Net/C#에 더 익숙하기 때문에.
일부 팀원은 기존 팀 스킬 세트, XSL 재능 또는 XSL이 배우기 쉽고 저렴하다는 믿음 때문에 XSL을 선호합니다.
Sitecore에서 ASP.NET 기반 하위 레이아웃은 실제로 XSL 렌더링보다 훨씬 뛰어납니다. 그것이 당신이 편안하게 느끼면, 그것을 위해 가십시오. 나는 결코 XSL 렌더링을 만들지 않았다.
XSLT는 강력한 언어입니다. ASP.NET과 같은 언어에 비해 주요 이점은 공통적 인 공유 요소 및 기타 가변 구조를 사용하여 매우 다양한 페이지 또는 다른 소스 문서 구조에서 논리를 재사용하고 사용자 정의하려는 경우에 나타납니다. 이를 달성하기 위해 규칙 기반 처리 모델을 사용합니다. 일부 모델에서는 처음 만났을 때 그립을 잡는 것이 꽤 어렵습니다. 그것이 시간이 지남에 갚을 투자이지만, 처음에는 힘들 수 있습니다.
성능면에서 볼 때 필자는 작업을 수행하기에 충분히 빠르지 않은 사이트를 보지 못했습니다. 사람들이 성능 문제를 겪었을 때 그들은 일반적으로 프로세싱 파이프 라인의 다른 부분에 있다고 밝혀졌습니다.
Sitecore를 구체적으로 참조하면 Sitecore가 구현되는 방식으로 인해 XSLT의 성능이 저하되는 경우가 있습니다. XML 구조는 매우 일반적인 것으로, 이름이 아닌 노드 값을 테스트하는 것을 의미합니다. 노드 깊이 또한 가능한 문제이므로 재귀 검색이 비쌉니다. Sitecore 구현에는 프로세서를 선택할 수 없지만 사용자 정의가 어렵지는 않습니다. 마지막으로 C#의 일부 XSLT 확장에 의존하기 때문에 자체적 인 단점이있을 수 있습니다. –
계속 ... Sitecore에서 본 것부터 .NET은 일반적으로 가장 기본적인 간단한 작업 이외의 작업을 수행하는 프레젠테이션 구성 요소를 추가하는보다 효율적인 방법입니다. 또한 대부분의 XSLT 개발자에게는 반 직관적 인 Sitecore XSLT 모범 사례 (For each 사용과 같은)가 있습니다. –
Sitecore의 XSLT와 .Net 구성 요소 사이의 선택은 주로 취향과 스킬 셋 중 하나입니다. Sitecore의 XSLT에는 .NET 구성 요소가 가장 단순한 렌더링을 제외하고 .NET 구성 요소보다 성능이 좋은 경향이 있으며 콘텐츠 트리 구조를 사이트 메뉴로 복제하는 등 가장 사용하기 쉬운 것처럼 보일 수 있습니다. 사실 가장 큰 성과를내는 경향이 있습니다. 올바른 상황에서 XSLT는 믿을 수 없을만큼 강력한 도구이며 학습 가치가 있지만 Sitecore에서 많이 사용하는 것에 대한 설득력있는 논거를 아직 보지 못했습니다. XSLT 프로그래밍의 표준 패턴 중 일부가 Sitecore에서 가장 효율적이지 않다는 점도 유의해야합니다.
내가 생각할 수있는 유일한 실질적인 이점은 XSLT 렌더링이 독립적으로 배포하기가 쉽다는 것입니다. 예를 들어, "뉴스 스팟"렌더링을 업데이트하고 있으며이 변경 사항을 테스트/제작에 즉시 배포하려는 경우 - .xsl 파일 자체를 업로드하는 간단한 경우 일 수 있습니다.
.NET 개발을 사용하고 웹 응용 프로그램 프로젝트 모델을 계속 사용하면 코드베이스를 배포하면 진행중인 작업을 포함하여 영향을받는 어셈블리에 모든 변경 내용이 암시 적으로 배포됩니다.
물론 관리 할 수있는 방법이 있습니다. 소스 코드를 분기/병합하는 등의 작업은 솔루션에 복잡성을 야기 할 수 있습니다. 내가 너무 있다는 것을 발견
을 : 말했다되고 그건
, 내가 너무 내 2 센트를 추가 할 것입니다
"소프트웨어 설계 및 코딩의 주 목표는 복잡성을 극복하는 것입니다. 많은 프로그래밍 관행의 동기는 프로그램의 복잡성을 줄이는 것입니다. 복잡성을 줄이는 것이 효과적인 프로그래머가되는 열쇠입니다." -Steve McConnell (1993)
XSLT를 C#을 사용할 때 사용하십시오.
이런 종류의 질문 ("Y 대신 X의 어택")은 주관적이고 논증적인 것입니다. –
@ 알레한드로 나는 그것을 다시보고 있다는데 동의합니다. 질문 수정에 대한 의견이 있으십니까? 그렇지 않다면 @James Walford의 답변을 수락 할 계획입니다. – JoshBaltzell