Trong khi học Sitecore tôi đã thấy rằng phần lớn mã mẫu Sitecore trên web là trong XSL thay vì .NET.Những lợi thế của việc sử dụng XSL trong Sitecore thay vì C# là gì?
Lợi thế của việc lựa chọn XSL qua các quy trình mà tôi đã trở nên quen thuộc với tư cách là nhà phát triển .NET là gì?
Có lợi thế về tốc độ xử lý khi sử dụng XSL không?
XSL có thực sự dễ dàng hơn khi bạn cảm thấy thoải mái với cú pháp không?
tôi sẽ chỉ cần thêm 2 cent của tôi quá:
tôi thấy rằng có quá nhiều hạn chế trong XSLT cần được khắc phục với "thư viện" bên ngoài hoặc với bạn phát triển một phương thức trong C# có thể được sử dụng trong XSLT.
Vì vậy, tôi tìm thấy bằng cách sử dụng Asp.Net đơn giản hơn. Nhưng sau đó tôi cũng tốt hơn rất nhiều với Asp.Net so với XSLT.
Nhưng XSLT có một số những điều tốt đẹp:
Khi lần đầu tiên tôi bắt đầu làm việc với Sitecore, công ty của tôi đã sử dụng khá một chút XSLT, nhưng chúng tôi đã từ từ biến mất. và bởi vì hầu hết mọi người ở đây quen thuộc hơn với Asp.Net/C#.
Một số người thích XSL vì nhóm kỹ năng hiện có, tính sẵn có của tài năng XSL, hoặc niềm tin rằng XSL dễ học hoặc rẻ hơn.
Trong Sitecore, lớp con dựa trên ASP.NET thực sự hoạt động tốt hơn nhiều so với kết xuất XSL. Nếu đó là những gì bạn cảm thấy thoải mái, hãy tiếp tục. Tôi chưa bao giờ tạo ra một XSL bản thân mình.
XSLT là một ngôn ngữ mạnh; lợi thế chính của nó trên các ngôn ngữ như ASP.NET có xu hướng đến khi bạn muốn sử dụng lại và tùy chỉnh logic trên nhiều trang khác nhau hoặc các cấu trúc tài liệu nguồn khác nhau với các thành phần chung và các cấu trúc biến khác. Để đạt được điều này, nó sử dụng một mô hình xử lý dựa trên quy tắc mà một số người thấy khá khó khăn để nắm bắt được trong lần gặp gỡ đầu tiên. Học nó là một khoản đầu tư sẽ trả hết theo thời gian, nhưng nó có thể khó khăn lúc đầu.
Về hiệu suất, tôi chưa bao giờ gặp một trang web không đủ nhanh cho công việc và bao gồm một số dịch vụ khá căng thẳng; khi mọi người gặp vấn đề về hiệu suất, chúng thường xuất hiện ở các phần khác của đường ống xử lý (hoặc đơn giản là do mã hóa xấu).
Với tham chiếu cụ thể đến Sitecore, tuy nhiên, XSLT có những hạn chế về hiệu suất trong một số trường hợp do cách Sitecore được triển khai. Cấu trúc XML là rất chung chung, có nghĩa là kiểm tra các giá trị nút thay vì tên. Độ sâu của nút cũng là một vấn đề có thể xảy ra, làm cho các tìm kiếm đệ quy tốn kém. Không có sự lựa chọn của bộ vi xử lý trong việc thực hiện Sitecore, mặc dù nó có thể sẽ không được tất cả những khó khăn để tùy chỉnh nó. Cuối cùng, nó cũng dựa vào một số phần mở rộng XSLT trong C#, có thể có những hạn chế riêng của nó. –
Tiếp tục .... Từ những gì tôi đã thấy trong Sitecore, .NET thường là cách hiệu quả hơn để thêm các thành phần trình bày làm bất cứ điều gì nhiều hơn các tác vụ đơn giản cơ bản nhất. Ngoài ra còn có một số thực hành tốt nhất của Sitecore XSLT (chẳng hạn như sử dụng cho mỗi) có tính phản trực giác đối với hầu hết các nhà phát triển XSLT. –
Lựa chọn giữa các thành phần XSLT và .Net trong Sitecore phần lớn là một trong những hương vị và kỹ năng. XSLT trong Sitecore có một số nhược điểm mặc dù nó có xu hướng hoạt động tốt hơn bởi các thành phần .NET cho tất cả, nhưng các render đơn giản nhất và những nơi có vẻ hợp lý nhất để sử dụng nó, chẳng hạn như tái tạo cấu trúc cây nội dung. thực sự là những người có xu hướng thực hiện hit hiệu suất lớn nhất. Trong những tình huống thích hợp, XSLT là một công cụ cực kỳ mạnh mẽ và đáng học hỏi, nhưng tôi vẫn chưa thấy một lập luận thuyết phục về việc sử dụng nó nhiều trong Sitecore. Cũng cần lưu ý rằng một số mẫu tiêu chuẩn của lập trình XSLT không hiệu quả nhất trong Sitecore.
Lợi thế thực sự duy nhất tôi có thể nghĩ đến, sẽ là hiển thị XSLT dễ triển khai hơn trong sự cô lập. Ví dụ: giả sử bạn đang cập nhật hiển thị "Tin tức Điểm ảnh" và bạn muốn triển khai thay đổi này để kiểm tra/sản xuất ngay lập tức - nó sẽ là một trường hợp đơn giản khi tải lên tệp .xsl.
Sử dụng phát triển .NET (và kéo dài mô hình Dự án ứng dụng Web), triển khai cơ sở mã sẽ ngầm triển khai bất kỳ và tất cả thay đổi đối với các hội đồng bị ảnh hưởng - bao gồm mọi công việc bạn đang thực hiện.
Có, tất nhiên, cách bạn có thể quản lý việc này. Phân nhánh mã nguồn/hợp nhất và vân vân - nhưng đó là một lớp phức tạp bổ sung cho giải pháp của bạn.
đó đang được nói, tôi sử dụng NET cho hơn 95% của tất cả các phát triển Sitecore tôi bản thân mình :-)
"Tóm lại, mục tiêu chính của thiết kế và mã hóa phần mềm là chinh phục sự phức tạp. Động lực đằng sau nhiều thực hành lập trình là giảm độ phức tạp của chương trình. Giảm phức tạp là chìa khóa để trở thành một lập trình viên hiệu quả." -Steve McConnell (1993)
Hãy để hướng dẫn đó khi sử dụng XSLT trên C#.
Nếu không có trường hợp sử dụng, loại câu hỏi này ("cuộc phiêu lưu của X thay vì Y") là chủ quan và tranh luận –
@Alejandro Tôi đồng ý rằng bây giờ tôi đang xem lại nó. Bất kỳ suy nghĩ nào về việc sửa đổi câu hỏi? Nếu không, tôi có kế hoạch chấp nhận câu trả lời từ @James Walford – JoshBaltzell