มีดโกนหรือ XSLT ดีกว่าสำหรับโครงการของฉันหรือไม่ [ปิด]

ฉันอยู่ในช่วงเริ่มต้นในการออกแบบระบบที่จะถูกแยกออกเป็นสองส่วน ส่วนหนึ่งคือบริการส่วนอีกส่วนหนึ่งเป็นส่วนต่อประสานกับบริการที่ให้ข้อมูลผ่านทาง OData หรือ XML แอปพลิเคชันจะขึ้นอยู่กับรูปแบบสถาปัตยกรรม MVC สำหรับมุมมองเรากำลังพิจารณาใช้ XSLT หรือ Razor ภายใต้ ASP.NET

XSLTหรือRazorจะช่วยแยกข้อกังวลโดยที่ XML ดั้งเดิมหรือการตอบสนองแทนแบบจำลองของคุณ XSLT หรือ 'Razor view' แทนมุมมองของคุณ ฉันจะปล่อยตัวควบคุมออกสำหรับตัวอย่างนี้ ข้อเสนอการออกแบบเบื้องต้นแนะนำ XSLT แต่ฉันแนะนำให้ใช้มีดโกนแทนเป็นเอ็นจิ้นการดูที่เป็นมิตรมากกว่า

นี่คือเหตุผลที่ฉันแนะนำให้ใช้กับมีดโกน (C #):

• ทำงานกับและสร้างเพจที่ซับซ้อนได้ง่ายขึ้น
• สามารถผลิตเอาต์พุตที่ไม่ใช่ * ML ได้อย่างง่ายดายเช่น csv, txt, fdf
• เทมเพลต verbose น้อยลง
• รูปแบบมุมมองถูกพิมพ์อย่างรุนแรงโดยที่ XSLT จะต้องพึ่งพาการประชุมเช่นค่าบูลีนหรือวันที่
• มาร์กอัปสามารถเข้าถึงได้ง่ายขึ้นเช่นการขึ้นบรรทัดใหม่การปรับมาตรฐานค่าการปรับมาตรฐานและกฎช่องว่าง
• สร้างขึ้นในตัวช่วย HTML สามารถสร้างรหัสตรวจสอบ JS ตามคุณลักษณะ DTO
• สร้างขึ้นในตัวช่วย HTML สามารถสร้างลิงก์ไปยังการกระทำได้

และอาร์กิวเมนต์สำหรับ XSLT บนมีดโกนคือ:

• XSLT เป็นมาตรฐานและจะยังคงมีอยู่อีกหลายปีในอนาคต
• เป็นการยากที่จะย้ายตรรกะไปยังมุมมองโดยไม่ตั้งใจ
• easer สำหรับโปรแกรมเมอร์ที่ไม่ใช่ (ซึ่งฉันไม่เห็นด้วย)
• มันประสบความสำเร็จในบางโครงการที่ผ่านมาของเรา
• ค่าข้อมูลจะถูกเข้ารหัส HTML โดยค่าเริ่มต้น
• ก่อตัวได้ดีเสมอ

ดังนั้นฉันกำลังมองหา aguments ทั้งสองข้างคำแนะนำหรือประสบการณ์ใด ๆ ที่สร้างทางเลือกที่คล้ายกัน?

ฉันได้ใช้ประสบความสำเร็จ XSLT เป็นเงินกองทุนชั้นที่นำเสนอเว็บ ... ในปี 1999 ในช่วง 12 ปีที่ผ่านมาตัวเลือกที่ดีมากได้มาพร้อม ทำตัวเองชอบมากและใช้มีดโกน ด้วยความยินดี.

นี่คือการเปรียบเทียบไวยากรณ์พื้นฐาน

มีดโกน

@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>

แหล่งข้อมูลสำหรับสองตัวอย่าง

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>

ค#

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"
    }
};

มีความสัมพันธ์แบบ 1: 1 ระหว่างเพจ HTML กับเอาต์พุต XML หรือไม่ พิจารณากรณีต่อไปนี้:

• ความสัมพันธ์ที่ดี: แต่ละหน้าเว็บมี HTML และรูปแบบ XML ที่สอดคล้องกัน

ตัวอย่าง: คุณกำลังโฮสต์เว็บไซต์พร้อมบทวิจารณ์ภาพยนตร์ คุณมีหน้าแรกพร้อมบทวิจารณ์ล่าสุดหนึ่งหน้าต่อบทวิจารณ์และหน้าเว็บที่มีความคิดเห็นและการให้คะแนนของแขก ไม่มีการลงทะเบียนใด ๆ คุณต้องการทำให้การใช้งานเว็บไซต์เป็นเรื่องง่ายโดยไม่ต้องมีการแยกวิเคราะห์ HTML ที่น่าเกลียด ในกรณีนี้คุณสามารถมีความสัมพันธ์แบบ 1: 1: มนุษย์ทุกคนสามารถทำได้บอทก็สามารถทำได้เช่นกัน: ด้วยคำขอเดียวกันพวกเขาจะได้รับเนื้อหาเดียวกัน

http://example.com/Movie/View/12345/The%20Adjustment%20 สำนักงานถูกใช้โดยมนุษย์
http://example.com/Movie/View/12345/BOT%20Adjustment%20Bureau?xmlจะถูกใช้โดยบอตเพื่อเข้าถึงข้อมูลเดียวกัน

• อ่อนแอหรือไม่มีความสัมพันธ์กัน: มีเพียงเว็บบริการด้านหนึ่งและอีกหลายหน้าเว็บ

ตัวอย่าง: คุณเป็นผู้สร้าง Facebook อื่น มีเว็บไซต์และมี API จุดร่วมเพียงอย่างเดียวคือใช้ฐานข้อมูลเดียวกัน แต่บอตไม่สามารถเข้าถึงสิ่งที่ผู้คนสามารถทำได้และข้อมูลจะถูกนำเสนอแตกต่างกัน

http://example.com/MyFriends/แสดงเพื่อนสิบอันดับแรกที่ฉันมีในบัญชีของฉัน เมื่อคลิก "เพิ่มเติม" จะมีการร้องขอ AJAX แสดงเพื่อนคนอื่น ๆ
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xmlแสดง XML ที่เกี่ยวข้องกับเพื่อนทุกคนที่ฉันมี

คุณจะเห็นว่า:

• API โฮสต์แยกต่างหากบนเซิร์ฟเวอร์ที่แตกต่างกัน
• ความสัมพันธ์ระหว่างหน้ากับ API นั้นยากที่จะมองเห็น
• เว็บไซต์จำเป็นต้องใช้เซสชันเพื่อติดตามการเข้าสู่ระบบ API ต้องการเพียงคีย์ที่สร้างขึ้นเพื่อส่งในทุกคำขอ
• จำนวนคำขอไม่เท่ากัน ในกรณีหนึ่งคุณต้องค้นหาหน้าจากนั้นทำคำขอ AJAX เพื่อรับเพื่อนที่เหลือของคุณ ในกรณีอื่นคุณจะได้รับรายการทั้งหมดในครั้งเดียว
• ข้อมูลที่ส่งคืนไม่เหมือนกัน ในฐานะมนุษย์คุณระบุเพื่อนของคุณด้วยชื่อของพวกเขา บอทที่ใช้ API จะระบุด้วยตัวระบุที่ไม่ซ้ำซึ่งคุณอาจไม่เคยเห็นในเว็บไซต์

ผมขอแนะนำให้เลือก XSLT เฉพาะถ้าคุณอยู่ใกล้ 1: 1 ความสัมพันธ์ ในกรณีนี้มันจะลดความซับซ้อนของวิธีการ: แอปพลิเคชันจะปล่อย XML ทุกครั้ง แต่บางครั้งก็เปลี่ยนเป็น XSLT สำหรับเบราว์เซอร์

หากคุณไม่มีความสัมพันธ์นี้ฉันไม่เห็นประโยชน์ใด ๆ ของ XSLT ผ่านทางมีดโกน มันเป็นการแยกความกังวลที่มีดโกนให้เช่นกัน ช่วยให้คุณสามารถแก้ไข HTML ได้โดยไม่จำเป็นต้องคอมไพล์เว็บไซต์ซ้ำอีกครั้งซึ่ง Razor ก็อนุญาตเช่นกัน

สำหรับผลประโยชน์ที่คุณระบุไว้:

XSLT เป็นมาตรฐานและจะยังคงมีอยู่อีกหลายปีในอนาคต

คุณวางแผนที่จะสร้างแอพพลิเคชั่นซึ่งจะใช้เวลานานมากหรือไม่? มีดโกนมีโอกาสที่จะใช้ในสี่ปีหรืออย่างน้อยได้รับการสนับสนุน อายุการใช้งานของแอปพลิเคชันส่วนใหญ่น้อยกว่าสี่ปีดังนั้น ...

easer สำหรับโปรแกรมเมอร์ที่ไม่ใช่ (สิ่งที่ฉันสามารถต่อสู้กับ)

รออะไร?! แม้แต่โปรแกรมเมอร์ก็พบว่า XSLT แย่มากเข้าใจยากและใช้งานได้ยาก และเมื่อฉันพูดคุยกับผู้ที่ไม่ได้เขียนโปรแกรมเกี่ยวกับ XML (ไม่ใกล้เคียงกับ XSLT) พวกเขาร้องไห้และวิ่งหนีไป

มันประสบความสำเร็จในบางโครงการที่ผ่านมาของเรา

หากทีมของคุณไม่เคยใช้มีดโกนมาก่อนให้พิจารณาเวลาที่ต้องใช้ในการเรียนรู้

หากทีมของคุณใช้ แต่โครงการเหล่านั้นล้มเหลวให้ลองวิเคราะห์ว่าทำไมมันถึงล้มเหลวและเป็นเพราะมีดโกนและคุณจะทำอย่างไรเพื่อหลีกเลี่ยงความล้มเหลวดังกล่าวในโครงการในอนาคต

คำแนะนำของฉันคือมีดโกนและเหตุผลหลักคือการทำงานกับมันง่ายกว่า (มากกว่า XSLT และตรงข้ามกับอาร์กิวเมนต์ที่คุณแจกให้แก่ XSLT แม้ว่าคุณอยู่ข้างฉัน) ฉันมีประสบการณ์ในการทำงานกับทั้งสองและมีดโกนจะมีประสิทธิภาพเป็นพิเศษในข้อความสั่งแบบมีเงื่อนไขผู้ช่วยในการประกาศ

ท้ายที่สุดอย่าลืมว่ามีดโกนคือภาษาการเขียนโปรแกรม (ใช่เทมเพลตเอนจิ้นหรือดูเอ็นจิ้น แต่ถูกนำไปใช้ผ่านภาษาการเขียนโปรแกรมเช่น C # หรือ VB.NET) ในขณะที่ XSLT มีโครงสร้างมาร์กอัปมากขึ้น

ฉันคิดว่าสถานการณ์ของคุณเป็นเหมือนการพยายามเลือก C # หรือ T-SQL เพื่อเขียนแอปพลิเคชันทางธุรกิจที่ซับซ้อน ในขณะที่ T-SQL นั้นค่อนข้างมีประสิทธิภาพในการตั้งค่ามันจะแตกเมื่อคุณพยายามใช้ตรรกะ (if-else, switch, for, etc. ) ในนั้น

คุณไม่ต้องเลือกคุณสามารถใช้ทั้งคู่ ใน ASP.NET MVC คุณสามารถใช้เอนจิ้นการดูหลายรายการพร้อมกันได้ ในโครงการฉันกำลังทำงานกับฉันใช้ XSLT สำหรับมุมมองแบบอ่านอย่างเดียวและมีดโกนสำหรับแบบฟอร์ม คุณยังสามารถใช้ XSLT ด้วยรูปแบบของมีดโกนหรือมีดโกนที่มีรูปแบบ XSLT ฉันกำลังใช้โครงร่าง XSLT ดังนั้นฉันก็แค่ใช้เลย์เอาต์แบบมีดโกนที่เรียกเลย์เอาต์ XSLT และผ่านส่วน HTML เป็นพารามิเตอร์:

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

... และในตัวhtmlRaw.xslคุณเพียงแค่ใช้disable-output-escaping="yes":

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

ดูการใช้มีดโกนและ XSLT ในโครงการเดียวกัน

ฉันขอแนะนำให้มีวิธีที่สามและดีกว่า: วางส่วนหน้าบางสองที่แตกต่างกันไว้ด้านบนของเลเยอร์บริการ / แอปพลิเคชันเดียวซึ่งไม่มี UI ดังกล่าว

ดังนั้นมากกว่า

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

ใช้

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

และตรวจสอบให้แน่ใจว่า UI และบริการมีรหัสเท่านั้นที่ไม่ซ้ำกับส่วนติดต่อนั้น (ขออภัยสำหรับแผนภาพ ASCII ที่ดีที่สุดที่ฉันสามารถทำได้ในตอนนี้)

เหตุผลที่ฉันจะกังวลเกี่ยวกับการออกแบบที่คุณกำลังพูดถึงคือมันเชื่อมโยงการพัฒนาส่วนต่อประสานผู้ใช้กับการพัฒนาบริการซึ่งไม่ค่อยเป็นวิธีที่คุณต้องการทำงาน หากธุรกิจต้องการเพิ่มฟังก์ชันการทำงานลงในส่วนติดต่อผู้ใช้คุณไม่ต้องการถูกบังคับให้เขียนบริการดังกล่าวก่อนที่จะทำ คุณต้องการที่จะเขียนส่วนต่อประสานผู้ใช้จากนั้นสมมติว่ามันจำเป็นต้องมีในการบริการใช้รหัสซ้ำที่นั่น

ถ้าธุรกิจต้องการแสดงข้อมูลที่แตกต่างอย่างมากกับผู้ใช้ปลายทางจากการนำเสนอต่อผู้ใช้เชิงกลผ่านบริการ (ซึ่งดูเหมือนว่ามีแนวโน้มสูง) คุณจะต้องเริ่มวางโค้ดที่ซับซ้อนใน XSLT หรือ สร้างเลเยอร์บริการที่สอง (หรือแย่กว่านั้นคือคอนโทรลเลอร์ไขมัน) ด้านบนของบริการของคุณเพื่อแสดงการนำเสนอต่อผู้ใช้

คิดเกี่ยวกับการตรวจสอบในกรณีนี้ คุณอาจวาดสามระดับความไว้วางใจ โมเดลของคุณจะต้องมีการตรวจสอบเพื่อให้แน่ใจว่าคุณไม่ได้เก็บข้อมูลที่ไม่ถูกต้อง บริการของคุณอาจต้องมีการตรวจสอบเพิ่มเติมเพื่อให้มั่นใจว่าผู้บริโภคภายนอกจะไม่พยายามทำสิ่งที่พวกเขาไม่ได้รับอนุญาตให้ทำ และ UI ของคุณจะต้องมีกฎการตรวจสอบที่ดีที่สุดเพื่อหลีกเลี่ยงการโพสต์กลับ

และนี่คือก่อนที่เราจะแตะต้องสถานการณ์ที่ยากลำบากของสิ่งที่ไม่ควรได้รับอนุญาตผ่าน API แต่ควรได้รับอนุญาตผ่าน UI ซึ่งต้องใช้ API

ฉันได้ยินข้อโต้แย้งว่าการใช้งาน UI ของคุณผ่านบริการของคุณนั้นเป็นเรื่องที่น่าสนใจและดีสำหรับคุณภาพของบริการ แต่ฉันขอแนะนำอย่างยิ่งว่าจะมีวิธีที่ดีกว่าในการทำเช่นนั้นในขณะที่แยกข้อกังวลระหว่างบริการ UI และรูปแบบธุรกิจ

ทั้งหมดนี้กล่าวว่าหากคุณต้องใช้บริการ UI ของคุณฉันขอแนะนำ Razor มากกว่า XSLT

XSLT เป็นมาตรฐานใช่ แต่ XSLT 2.0 ยังคงมีการสนับสนุนที่ จำกัด ดังนั้นคุณจึงติดอยู่กับมาตรฐานที่ล้าสมัยหากคุณต้องการโต้แย้ง

XSLT ไม่ใช่เรื่องง่ายที่จะอ่าน โดยทุกคนที่ไม่ใช่ผู้เชี่ยวชาญ XSLT คุณคิดว่าใครหาได้ง่ายกว่าเมื่อคุณต้องการจ้างพนักงานใหม่ มีคนอ้างว่าเป็นผู้เชี่ยวชาญ XSLT หรือ ASP.NET สำหรับผู้เชี่ยวชาญ MVC หรือไม่

และใช่ฉันเห็น XSLT ใช้สำเร็จแล้ว แต่ก่อนที่ MVC สำหรับ ASP.NET จะเป็นตัวเลือก