Thật khó để đánh giá các công nghệ khi bạn không có kinh nghiệm sâu sắc về chúng, nhưng tất nhiên đó chính xác là khi bạn phải đưa ra quyết định của mình, vì vậy không có câu trả lời đơn giản nào cho vấn đề nan giải đó.
Bạn trích dẫn hai mối quan tâm: hiệu suất và khả năng sử dụng. Tôi sẽ cố gắng giải quyết cả hai bên dưới.
Thứ nhất, hiệu suất. Hiệu suất của khóa học không chỉ phụ thuộc vào ngôn ngữ mà còn phụ thuộc vào việc thực hiện và cũng phụ thuộc vào chuyên môn của người dùng. Các bộ xử lý XSLT khác nhau có thể khác nhau về hiệu năng và cùng một bộ xử lý có thể khác nhau tùy thuộc vào cách sử dụng (ví dụ với Saxon, những người gặp vấn đề về hiệu năng thường sử dụng nó với DOM, một sự kết hợp kém và hiệu suất có thể tăng gấp mười lần nếu bạn sử dụng mô hình cây bản địa của Saxon thay thế). Vì vậy, lời khuyên đầu tiên là đừng thực hiện việc nghe, hãy đo nó; và lời khuyên thứ hai là đảm bảo rằng người thực hiện phép đo có đủ kinh nghiệm để không mắc phải những sai lầm ngớ ngẩn. Nói dễ hơn làm.
Một cách thô bạo, bạn có thể tách các công việc chuyển đổi thành hai loại: đơn giản và phức tạp. Đối với các phép biến đổi đơn giản, với bộ xử lý XSLT tốt, thời gian dành cho việc phân tích cú pháp và tuần tự hóa và thời gian xử lý XSLT hầu như không xuất hiện trong ảnh. Vì bất kỳ công nghệ nào khác sẽ phải chịu cùng một chi phí phân tích và tuần tự hóa, sự lựa chọn công nghệ chuyển đổi sẽ không tạo ra sự khác biệt lớn (ngoại trừ rất có thể mã hóa ở mức độ rất thấp sử dụng phát trực tuyến, nhưng không nhiều người có thể đủ khả năng lập trình thời gian và kỹ năng cần thiết để thực hiện điều đó). Đối với các phép biến đổi phức tạp trên các tài liệu lớn, bạn bắt đầu gặp các vấn đề tương tự như với lập trình SQL: để đạt được hiệu suất tốt đòi hỏi sự tương tác tốt giữa các kỹ năng và kiến thức của lập trình viên và khả năng của trình tối ưu hóa. Như với SQL, nó ' Rất dễ dàng trong một ngôn ngữ cấp cao như vậy để viết một vài câu lệnh đơn giản dẫn đến việc bộ xử lý phải thực hiện một khối lượng công việc rất lớn. Nhưng cũng như với SQL, các lập trình viên biết những gì họ đang làm sẽ làm tốt hơn nhiều so với người mới.
Thứ hai, khả năng sử dụng. Cú pháp dựa trên XML cho XSLT rất không phù hợp với nhiều người trong lần gặp gỡ đầu tiên với ngôn ngữ này. Nhưng có những lý do chính đáng và lợi ích thực sự để làm theo cách này: có đối số "khuôn mẫu", rằng rất nhiều mã bao gồm XML được ghi vào tài liệu kết quả và cách tốt nhất để viết XML là bằng XML. Và có tranh luận "phản ánh"; trong các hệ thống phức tạp lớn, rất phổ biến để tìm các bảng định kiểu tạo ra các bảng định kiểu. Sau đó là đối số "công cụ"; nếu bạn đang ở trong một cửa hàng XML, có lẽ bạn có rất nhiều công cụ XML như các trình soạn thảo hướng cú pháp và thật tốt khi có thể sử dụng cùng các công cụ để xử lý các chương trình và dữ liệu của bạn. Những nhược điểm hóa ra là khá mỹ phẩm khi so sánh: có ' là số lượng tổ hợp phím liên quan đến chỉnh sửa (dễ dàng sửa chữa bằng một công cụ chỉnh sửa tốt) và có độ dài của mã (giảm khả năng đọc của nó). Mức độ chi tiết giảm đáng kể trong XSLT 2.0 với việc giới thiệu các tính năng như biểu thức thông thường và chức năng biểu định kiểu: nhiều biểu định kiểu được giảm xuống một nửa hoặc một phần ba kích thước khi chúng tận dụng tối đa XSLT 2.0.
Việc bạn đề cập đến DSSSL để lại cho tôi một nụ cười gượng gạo. Tôi chưa bao giờ sử dụng DSSSL, nhưng những câu chuyện tôi nghe được là nó không có tác dụng vì cú pháp của nó rất phức tạp và không liên quan đến cú pháp của dữ liệu (SGML). Việc sử dụng cú pháp XML cho XSLT được thúc đẩy mạnh mẽ bởi kinh nghiệm với DSSSL.
Có những người yêu thích XSLT và có những người ghét nó. Không có gì đáng ngạc nhiên, những người sử dụng nó rất nhiều có xu hướng rơi vào loại đầu tiên. Những người không thích nó thường là những người chưa học cách "nghĩ theo cách XSLT". Bạn có thể lập luận rằng một ngôn ngữ lập trình không nên ảnh hưởng đến cách bạn nghĩ, nhưng thực tế là: viết bằng ngôn ngữ dựa trên quy tắc sẽ có suy nghĩ khác với viết bằng ngôn ngữ bắt buộc. Phản ứng đầu tiên của nhiều lập trình viên là họ cảm thấy ít kiểm soát hơn (mô tả vấn đề, thay vì nói cho máy tính biết phải làm gì từng bước một). Nó rất giống với phản ứng bạn từng thấy khi mọi người lần đầu tiên được giới thiệu về SQL. Ngày nay, mọi người học SQL sớm hơn trong sự nghiệp của họ để yêu cầu điều chỉnh tinh thần ít hơn.
Cuối cùng, bạn nên chọn một công nghệ dựa trên các tiêu chí đo lường khách quan, không dựa trên các phản ứng yêu / ghét. Thật khó để thực hiện những phép đo đó. Nhưng có rất nhiều người sử dụng XSLT rất chuyên sâu và rất thành công, vì vậy không có gì phải nghi ngờ rằng nó có thể được thực hiện.