LINQ to XML이 XSLT를 대체합니까?

Question

LINQ to XML에서 수행 할 수없는 내용이 XSLT에 있습니까? XSLT를 배우는 것이 여전히 중요합니까? 언제 다른 것을 선택합니까? .NET

Answer 1

Linq to XML에서 수행 할 수없는 XSLT에서 수행 할 수있는 작업이 있습니까? XML로, 프로그래밍 언어 튜링 완성에 의해 사용되는 API이며, (예를 들어, 당신이 완전히 L2X에 텍스트와 CDATA 노드 사이의 차이를 제어 할 수 있습니다) 않습니다 XSLT 문서 모델보다 XML 인포 셋을 더 포함 LINQ 이후

없음

, .

XSLT를 배우는 것이 여전히 중요합니까?

현재 진행 상황에 따라 다릅니다. 대체로 말하자면, 그렇습니다.

언제 다른 하나를 선택 하시겠습니까?

변환을 수행해야 할 때 일반적으로 XSLT가 더 좋습니다. 즉, 입출력 모두 XML입니다. 그 이유는 여러 가지가 있습니다. 우선 XSLT 패턴 매칭은 일반적으로 L2X 쿼리에서 중첩 된 ?:보다 간결하며 훨씬 읽기 쉽습니다. *을 사용하여 기본 규칙 (예 : "모든 항목 복사"또는 "자식 처리하지만 출력을 생성하지 않음")을 설정 한 다음 특별한 방법으로 처리해야하는 특정 노드에 대한 규칙을 추가 할 수 있습니다. L2X에서 자주하는 것처럼 문서의 각 노드 레벨에 대해 명시적인 루프/이해를 작성할 필요가 없습니다. 마지막으로, XPath는 L2X 쿼리 (적어도 C#에서는)보다 간결하므로 쿼리를 많이하지 않으면 XSLT에서 훨씬 더 짧고 읽기 쉽습니다.

L2X는 일반적으로 문서에서 특정 값이나 노드를 빠르게 쿼리해야 할 때 더 좋습니다. 가장 큰 이점은 런타임 오버 헤드가 적어 (XPath를 구문 분석해야하고 L2X 쿼리는 필요하지 않음) XmlNamespaceManager 및 기타 cruft를 사용하지 않아도됩니다. API가 단일 표현식 쿼리를 작성하기 위해 간소화되었습니다. 또한 from 루프와 let을 중첩하면 XQuery 영역에 더 가깝습니다.

L2X는 문서의 전체 업데이트가 필요한 유일한 옵션이며 문서에서 몇 가지 값만 바꾸면되고 내부 업데이트는 옵션입니다. XSLT 어떤 식 으로든 입력을 만지는 것을 허용하지 않습니다.

Answer 2

되지는 XSLT 내용을 확실히 여전히 중요하다. LINQ to XML은 훌륭하지만 .NET Apps 만 사용할 수 있습니다.

XSLT는 언어와 플랫폼간에 적용 할 수 있습니다 ... 심지어 브라우저는 XML을 가져 와서 출력을 생성하기 위해 XSLT를 적용 할 수 있습니다.

일부 .NET 응용 프로그램 API (예 : CMS 시스템)는 여전히 내부 XML을 출력으로 변환하기 위해 XSLT를 제공해야한다는 것을 잊지 마십시오. 기술을 모두 무시하면 내 의견으로는 실수가 될 수 있습니다.

Answer 3

를 사용하지 않는 사람을위한