Là dao cạo hoặc XSLT tốt hơn cho dự án của tôi? [đóng cửa]

Tôi đang ở giai đoạn đầu trong việc thiết kế một hệ thống về cơ bản sẽ được chia thành hai phần. Một phần là dịch vụ và phần khác là giao diện với dịch vụ cung cấp dữ liệu thông qua một cái gì đó như OData hoặc XML. Ứng dụng sẽ dựa trên mô hình kiến ​​trúc MVC. Đối với các khung nhìn, chúng tôi đang xem xét sử dụng XSLT hoặc Dao cạo trong ASP.NET.

XSLT hoặc Dao cạo sẽ giúp phân tách các mối quan tâm trong đó XML hoặc phản hồi ban đầu đại diện cho mô hình của bạn, XSLT hoặc 'Chế độ xem dao động' thể hiện quan điểm của bạn. Tôi sẽ để bộ điều khiển ra cho ví dụ này. Đề xuất thiết kế ban đầu đề xuất XSLT, tuy nhiên tôi đã đề xuất sử dụng Dao cạo thay vì làm công cụ xem thân thiện hơn.

Đây là những lý do tôi đề xuất cho Dao cạo (C #):

• Dễ dàng hơn để làm việc với và xây dựng các trang phức tạp hơn.
• Có thể dễ dàng tạo đầu ra không * ML, ví dụ: csv, txt, fdf
• Mẫu ít dài dòng
• Mô hình khung nhìn được gõ mạnh, trong đó XSLT sẽ cần dựa vào quy ước, ví dụ: giá trị boolean hoặc ngày
• Đánh dấu là dễ tiếp cận hơn, ví dụ: bình thường, chuẩn hóa dòng mới, chuẩn hóa giá trị attibute, quy tắc khoảng trắng
• Trình trợ giúp HTML tích hợp có thể tạo mã xác thực JS dựa trên các thuộc tính DTO
• Trình trợ giúp HTML tích hợp có thể tạo liên kết đến các hành động

Và các đối số cho XSLT về dao cạo là:

• XSLT là một tiêu chuẩn và vẫn sẽ tồn tại trong nhiều năm tới.
• Thật khó để vô tình di chuyển logic vào chế độ xem
• Easer cho người không lập trình (mà tôi không đồng ý).
• Nó đã thành công trong một số dự án trước đây của chúng tôi.
• Giá trị dữ liệu được mã hóa HTML theo mặc định
• Luôn luôn hình thành tốt

Vì vậy, tôi đang tìm kiếm thông tin ở hai bên, các khuyến nghị hoặc bất kỳ kinh nghiệm nào để đưa ra lựa chọn tương tự?

Tôi ĐÃ sử dụng thành công XSLT như một tầng presentation web ... vào năm 1999. Trong 12 năm trở lại đây, các lựa chọn tốt hơn nhiều có đi cùng. Làm cho mình một lợi ích lớn, và sử dụng dao cạo. Đó là một vinh dự.

Đây là một so sánh cú pháp cơ bản

Dao cạo

@foreach(var item in View.List) {
  <span>@item.Name</span><br/>
}

XSLT

  <xsl:template match="/">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

Các nguồn dữ liệu cho hai ví dụ

XML

<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
<list>
    <item>
        <name>List item one</name>
        <url>http://site.com/one</url>
    </item>
    <item>
        <name>List item two</name>
        <url>http://site.com/two</url>
    </item>
</list>

C #

ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    },
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
    }
};

Có mối quan hệ 1: 1 giữa các trang HTML và đầu ra XML không? Xem xét các trường hợp sau:

• Tương quan mạnh mẽ: mỗi trang web có một HTML và một dạng XML tương ứng.

Ví dụ: bạn đang lưu trữ một trang web với các đánh giá phim. Bạn có một trang chủ với các đánh giá mới nhất, một trang cho mỗi đánh giá và một trang có nhận xét và xếp hạng của khách. Không có đăng ký nào. Bạn muốn làm cho nó dễ dàng sử dụng trang web của bạn theo chương trình mà không cần phân tích cú pháp HTML xấu xí. Trong trường hợp này, bạn có thể có mối quan hệ 1: 1: tất cả con người có thể làm, bot cũng có thể làm như vậy: với cùng một yêu cầu, họ sẽ có được cùng một nội dung.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau được sử dụng bởi con người.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml được sử dụng bởi các bot để truy cập cùng thông tin.

• Yếu hoặc không có mối tương quan: chỉ có một loạt các dịch vụ web ở một bên và một loạt các trang web ở bên kia.

Ví dụ: bạn là người tạo ra một Facebook khác. Có một trang web và có một API. Điểm chung duy nhất là cùng một cơ sở dữ liệu được sử dụng, nhưng các bot không thể truy cập vào những gì mọi người có thể và thông tin được trình bày khác nhau.

http://example.com/MyFriends/ hiển thị mười người bạn hàng đầu tôi có trong tài khoản của mình. Bằng cách nhấp vào "Khác", yêu cầu AJAX được thực hiện, hiển thị cho những người bạn khác.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml hiển thị XML tương ứng với tất cả bạn bè tôi có.

Bạn có thể thấy rằng:

• API được lưu trữ riêng, trên một máy chủ riêng biệt,
• Mối quan hệ giữa các trang và API rất khó thấy.
• Trang web cần sử dụng phiên để theo dõi đăng nhập. API chỉ cần một khóa được tạo để được gửi theo mọi yêu cầu.
• Số lượng yêu cầu không giống nhau. Trong một trường hợp, bạn phải truy vấn trang, sau đó thực hiện yêu cầu AJAX để có được phần còn lại của bạn bè. Trong trường hợp khác, bạn có được toàn bộ danh sách cùng một lúc.
• Các thông tin trả lại không giống nhau. Là một con người, bạn xác định bạn bè của mình bằng tên của họ. Một bot sử dụng API sẽ xác định chúng bằng mã định danh duy nhất của chúng mà bạn có thể không bao giờ thấy trên trang web.

Tôi khuyên bạn chỉ nên chọn XSLT nếu bạn ở gần mối quan hệ 1: 1 . Trong trường hợp này, nó sẽ đơn giản hóa cách tiếp cận: ứng dụng sẽ phát ra XML mỗi lần, nhưng đôi khi chuyển đổi nó bằng XSLT cho các trình duyệt.

Nếu bạn không có mối quan hệ này, tôi sẽ không thấy bất kỳ lợi ích nào của XSLT so với Dao cạo. Nó cung cấp một sự tách biệt các mối quan tâm mà dao cạo cung cấp quá. Nó cho phép bạn sửa đổi HTML mà không cần phải biên dịch lại trang web, điều mà Razor cũng cho phép.

Đối với những lợi ích bạn đã liệt kê:

XSLT là một tiêu chuẩn và sẽ còn tồn tại trong nhiều năm tới

Bạn có kế hoạch để làm cho một ứng dụng sẽ sống trong một thời gian rất dài? Dao cạo có cơ hội được sử dụng trong bốn năm, hoặc ít nhất là được hỗ trợ. Tuổi thọ của hầu hết các ứng dụng là dưới bốn năm, vì vậy ...

Easer cho người không lập trình (một cái gì đó tôi có thể tranh luận).

Đợi đã, cái gì?! Ngay cả các lập trình viên cũng thấy rằng XSLT tệ, khó hiểu và khó sử dụng. Và khi tôi nói chuyện với những người không lập trình về XML (thậm chí không gần với XSLT), họ khóc và bỏ chạy.

Nó đã thành công trong một số dự án trước đây của chúng tôi.

Nếu nhóm của bạn chưa bao giờ sử dụng Dao cạo trước đó, thì hãy xem xét thời gian cần thiết để học nó.

Nếu nhóm của bạn đã sử dụng nó, nhưng những dự án đó đã thất bại, hãy xem xét phân tích lý do tại sao nó thất bại và đó là do Dao cạo, và bạn có thể làm gì để tránh những thất bại như vậy trong các dự án trong tương lai.

Đề xuất của tôi là Dao cạo và lý do chính là nó hoạt động dễ dàng hơn nhiều (so với XSLT, và ngược lại với đối số được liệt kê của bạn ủng hộ XSLT, mặc dù, bạn đứng về phía tôi). Tôi có kinh nghiệm làm việc với cả hai và Dao cạo trở nên đặc biệt mạnh mẽ trong các tuyên bố có điều kiện, người trợ giúp khai báo (chức năng trong hiệu trưởng), phân nhánh, lặp, v.v.

Xét cho cùng, đừng quên Dao cạo là ngôn ngữ lập trình (vâng, công cụ mẫu hoặc công cụ xem, nhưng được triển khai thông qua ngôn ngữ lập trình như C # hoặc VB.NET), trong khi XSLT có nhiều cấu trúc đánh dấu hơn.

Tôi nghĩ kịch bản của bạn giống như cố gắng chọn C # hoặc T-SQL để viết một ứng dụng kinh doanh phức tạp. Mặc dù T-SQL khá mạnh trong các hoạt động thiết lập, nhưng nó chỉ bị hỏng khi bạn cố gắng thực hiện logic (if-other, switch, for, v.v.) trong đó.

Bạn không phải chọn, bạn có thể sử dụng cả hai. Trong ASP.NET MVC bạn có thể sử dụng nhiều công cụ xem cùng một lúc. Trong dự án tôi hiện đang làm việc trên Tôi đang sử dụng XSLT cho các chế độ xem chỉ đọc và Dao cạo cho các biểu mẫu. Bạn cũng có thể sử dụng XSLT với bố cục Dao cạo hoặc Dao cạo với bố cục XSLT. Tôi đang sử dụng bố cục XSLT, vì vậy tôi chỉ cần sử dụng bố cục Dao cạo gọi bố cục XSLT và chuyển các phần HTML dưới dạng tham số:

@{ 
   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }
   });
}

... và trong htmlRaw.xslbạn chỉ cần sử dụng disable-output-escaping="yes":

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>
</div>

Xem Sử dụng Dao cạo và XSLT trong cùng một dự án .

Tôi muốn đề xuất một cách thứ ba và tốt hơn: đặt hai mặt trước mỏng khác nhau lên trên một lớp dịch vụ / ứng dụng duy nhất không có giao diện người dùng như vậy.

Vì vậy, thay vì

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model

sử dụng

UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

và đảm bảo rằng UI và Dịch vụ chứa mã CHỈ duy nhất cho giao diện đó. (xin lỗi về sơ đồ ASCII, tốt nhất tôi có thể làm ngay bây giờ)

Lý do tôi sẽ quan tâm đến một trong những thiết kế mà bạn đang thảo luận là nó liên quan đến sự phát triển của giao diện người dùng với sự phát triển của dịch vụ, điều hiếm khi bạn muốn làm việc. Nếu doanh nghiệp muốn thêm một phần chức năng vào giao diện người dùng, bạn không muốn bị buộc phải viết dịch vụ đó trước khi bạn có thể làm điều đó. Bạn muốn viết phần giao diện người dùng và sau đó, giả sử nó được yêu cầu trong dịch vụ, sử dụng lại mã ở đó.

Tồi tệ hơn, nếu doanh nghiệp muốn hiển thị dữ liệu rất khác với người dùng cuối so với cách trình bày cho người dùng cơ học thông qua dịch vụ (có vẻ như rất có thể), bạn sẽ phải bắt đầu đưa mã phức tạp vào XSLT, hoặc xây dựng lớp dịch vụ thứ hai (hoặc tệ hơn là bộ điều khiển chất béo) trên đầu dịch vụ của bạn để thể hiện bản trình bày cho người dùng.

Hãy suy nghĩ về xác nhận trong trường hợp này. Bạn có khả năng rút ra ba cấp độ tin cậy. Mô hình của bạn sẽ yêu cầu xác thực để đảm bảo bạn không lưu trữ dữ liệu không hợp lệ; sau đó dịch vụ của bạn có thể yêu cầu một số xác nhận thêm, để đảm bảo rằng người tiêu dùng bên ngoài không cố gắng làm điều gì đó mà họ không được phép làm; và giao diện người dùng của bạn sẽ cần một số quy tắc xác thực, tốt nhất để nó có thể tránh được việc gửi lại.

Và đây là trước khi chúng ta thậm chí chạm vào tình huống dính của thứ gì đó không được phép thông qua API mà nên được cho phép thông qua UI, vốn yêu cầu API.

Tôi đã nghe một cuộc tranh luận rằng việc chạy UI của bạn thông qua dịch vụ của bạn là dogfooding và do đó tốt cho chất lượng dịch vụ, nhưng tôi thực sự khuyên bạn nên có những cách tốt hơn để làm điều đó trong khi vẫn giữ sự tách biệt (và RẮN) giữa các dịch vụ, UI và mô hình kinh doanh.

Tất cả điều này đã nói, nếu bạn phải đi theo cách gói dịch vụ của mình với một giao diện người dùng, tôi thực sự khuyên bạn nên sử dụng Dao cạo trên XSLT.

XSLT là một tiêu chuẩn, vâng. Nhưng XSLT 2.0 vẫn có hỗ trợ hạn chế, do đó bạn bị mắc kẹt với một tiêu chuẩn lỗi thời nếu bạn muốn đưa ra lập luận đó.

XSLT không dễ đọc. Bởi bất cứ ai không phải là chuyên gia XSLT. Bạn nghĩ ai dễ tìm hơn, khi bạn cần thuê nhân viên mới? Ai đó tự xưng là chuyên gia XSLT hoặc chuyên gia ASP.NET cho MVC?

Và vâng, tôi đã thấy XSLT được sử dụng thành công, nhưng chỉ trước khi MVC cho ASP.NET là một tùy chọn.