रेजर या XSLT मेरे प्रोजेक्ट के लिए बेहतर है? [बन्द है]

Question

मैं एक प्रणाली के डिजाइन में शुरुआती चरणों में हूं जो अनिवार्य रूप से दो भागों में विभाजित होगा। एक हिस्सा एक सेवा है और दूसरा एक इंटरफ़ेस है जिसमें सेवा ओडेटा या एक्सएमएल जैसी चीज़ों के माध्यम से डेटा प्रदान करती है। आवेदन MVC वास्तु पैटर्न पर आधारित होगा। विचारों के लिए, हम ASP.NET के तहत XSLT या रेजर का उपयोग करने पर विचार कर रहे हैं।

XSLT या रेज़र उन चिंताओं को अलग करने में मदद करेगा जहाँ मूल XML या प्रतिक्रिया आपके मॉडल का प्रतिनिधित्व करती है, XSLT या 'रेज़र व्यू' आपके विचार का प्रतिनिधित्व करता है। मैं इस उदाहरण के लिए नियंत्रक को छोड़ दूँगा। प्रारंभिक डिजाइन प्रस्ताव एक्सएसएलटी की सिफारिश करता है, हालांकि मैंने रेजर के उपयोग को एक अधिक अनुकूल दृश्य इंजन के रूप में उपयोग करने का सुझाव दिया।

ये कारण हैं जो मैंने रेज़र (C #) के लिए सुझाए हैं:

• अधिक जटिल पृष्ठों के साथ काम करना और निर्माण करना आसान है।
• आसानी से गैर- * ML आउटपुट, जैसे csv, txt, fdf का उत्पादन कर सकते हैं
• कम वर्बोस टेम्प्लेट
• व्यू मॉडल दृढ़ता से टाइप किया गया है, जहां XSLT को कन्वेंशन, जैसे बूलियन या डेट वैल्यू पर भरोसा करना होगा
• मार्कअप अधिक स्वीकार्य है, उदाहरण के लिए nbsp, newline normalization, attibute मान सामान्यीकरण, व्हाट्सएप नियम
• एचटीएमएल हेल्पर में निर्मित डीटीओ विशेषताओं के आधार पर जेएस सत्यापन कोड उत्पन्न कर सकता है
• HTML सहायक में निर्मित कार्यों के लिंक उत्पन्न कर सकता है

और रेज़र पर XSLT के तर्क थे:

• XSLT एक मानक है और अभी भी भविष्य में कई वर्षों तक मौजूद रहेगा।
• तर्क को गलती से दृश्य में ले जाना कठिन है
• गैर प्रोग्रामर के लिए इरेज़र (जो मैं सहमत नहीं हूँ)।
• यह हमारी पिछली कुछ परियोजनाओं में सफल रहा है।
• डेटा मान डिफ़ॉल्ट रूप से HTML- एन्कोडेड हैं
• हमेशा अच्छी तरह से गठित

तो मैं किसी भी पक्ष, सिफारिशों या किसी भी अनुभव को समान बनाने के लिए आंदोलन की तलाश कर रहा हूं?

Comments

2011 में XSLT के पक्ष में लोग बहस कर रहे हैं?

— वायट बार्नेट

जब कोई XSLT या ... पूछता है कि सही उत्तर तुरंत बाधित होने के बाद वे कहते हैं कि "दूसरा वाला!" कई स्थानों पर समर्थित होने के दौरान XSLT कोबोल या असेंबलर की तुलना में लगभग किसी अन्य विकल्प की तुलना में काम करने के लिए एक विशेष नरक है। XSLT का उपयोग केवल तब करें जब सभी आधुनिक विकल्पों को समाप्त कर दिया गया हो।

— बिल

Answer 1

मैं किया है सफलतापूर्वक एक वेब प्रस्तुति स्तर के रूप में इस्तेमाल किया ... XSLT 1999 में पिछले 12 वर्षों में, ज्यादा बेहतर विकल्प के साथ आए हैं। अपने आप को एक बड़ा एहसान करें, और रेज़र का उपयोग करें। यह एक खुशी की बात है।

Comments

अरे - क्या आप यह कहना चाहेंगे कि रेजर के अलावा आपके पास और क्या विकल्प हैं?

— बार्टोज़

यह उत्तर बहुत समय पहले था, इसलिए मुझे याद नहीं है कि मेरे मन में क्या था। लेकिन यहां तक ​​कि क्लासिक एएसपी एक्सएसएलटी, आईएमओ से बेहतर काम करेगा। वर्तमान में हम एंगुलर चले गए हैं।

— अफ्रीकी

Answer 2

यहाँ एक मूल वाक्यविन्यास तुलना है

उस्तरा

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

Comments

मुझे लगता है कि यह मर चुका है और खत्म हो गया है, लेकिन यह बताने में मदद नहीं कर सकता कि आपका अपना जवाब यहां इस बात का सही तर्क है कि आप क्यों और उम्मीद से रेजर के साथ गए थे और एक्सएसएल नहीं: आप स्पष्ट रूप से अनिवार्य प्रोग्रामिंग प्रतिमान के साथ अधिक सहज हैं कि रेजर चिपक जाता है एक्सएसएलटी अपने सबसे अच्छे (और सबसे कठिन) मॉडल में घोषित (क्वैसी-फंक्शनल) मॉडल बनाम बनाम। उदाहरण के लिए, टेम्पलेट मिलान के बजाय name(संभवत: एक अलग मोड में जाने के लिए), आप इसमें से प्रत्येक के लिए एक से भाग गए item। जबकि यह तकनीकी रूप से काम करता है, यह XSLT की ताकत के लिए खेलने में विफल रहता है। इसे एक (व्यक्तिगत) तर्क के रूप में नहीं किया जाना चाहिए।

— taswyn

Answer 3

क्या HTML पेज और XML आउटपुट के बीच 1: 1 संबंध है? निम्नलिखित मामलों पर विचार करें:

• मजबूत सहसंबंध: प्रत्येक वेब पेज में एक HTML और एक संबंधित XML रूप होता है।

उदाहरण: आप फिल्मों की समीक्षा के साथ एक वेबसाइट की मेजबानी कर रहे हैं। आपके पास नवीनतम समीक्षा के साथ एक पृष्ठ, समीक्षा के प्रति एक पृष्ठ और मेहमानों की टिप्पणियों और रेटिंग के साथ एक पृष्ठ है। कोई पंजीकरण नहीं है। आप बदसूरत HTML पार्सिंग के बिना अपनी वेबसाइट को प्रोग्रामेटिक रूप से उपयोग करना आसान बनाना चाहते हैं। इस मामले में, आपके पास 1: 1 संबंध हो सकता है: सभी मानव कर सकते हैं, बॉट भी कर सकता है: समान अनुरोधों के साथ, वे एक ही सामग्री प्राप्त करेंगे।

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau का उपयोग मानव द्वारा किया जाता है।
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml का उपयोग बॉट द्वारा समान जानकारी तक पहुंचने के लिए किया जाता है।

• कमजोर या कोई संबंध नहीं: एक तरफ सिर्फ वेब सेवाओं का एक गुच्छा है, और दूसरी तरफ वेब पृष्ठों का एक गुच्छा है।

उदाहरण: आप दूसरे फेसबुक के निर्माता हैं। एक वेबसाइट है, और एक एपीआई है। एकमात्र सामान्य बिंदु यह है कि एक ही डेटाबेस का उपयोग किया जाता है, लेकिन बॉट उन लोगों तक नहीं पहुंच सकते जो लोग कर सकते हैं, और जानकारी को अलग तरीके से प्रस्तुत किया जाता है।

http://example.com/MyFriends/ मेरे खाते के शीर्ष दस मित्रों को दिखाता है। "अधिक" पर क्लिक करके, अन्य मित्रों को दिखाते हुए एक AJAX अनुरोध किया जाता है।
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml मेरे पास मौजूद सभी मित्रों के साथ संबंधित XML दिखाता है।

आप वह देख सकते हैं:

• API को एक अलग सर्वर पर अलग से होस्ट किया जाता है,
• पृष्ठों और एपीआई के बीच का संबंध देखना मुश्किल है।
• लॉगऑन को ट्रैक करने के लिए वेबसाइट को सत्र का उपयोग करने की आवश्यकता है। एपीआई को हर अनुरोध पर भेजे जाने के लिए बस एक उत्पन्न कुंजी की आवश्यकता होती है।
• अनुरोधों की संख्या समान नहीं है। एक मामले में, आपको पृष्ठ को क्वेरी करना होगा, फिर अपने बाकी दोस्तों को प्राप्त करने के लिए एक AJAX अनुरोध करें। अन्य मामलों में, आप एक ही बार में पूरी सूची प्राप्त करते हैं।
• लौटाई गई जानकारी समान नहीं है। एक इंसान के रूप में, आप अपने दोस्तों को उनके नाम से पहचानते हैं। एपीआई का उपयोग करने वाला एक बॉट उनकी विशिष्ट पहचानकर्ता द्वारा उनकी पहचान करेगा जिसे आप वेबसाइट पर कभी नहीं देख सकते हैं।

---

मैं XSLT को केवल तभी चुनने की सलाह देता हूं जब आप 1: 1 संबंध के पास हों । इस मामले में, यह दृष्टिकोण को सरल करेगा: एप्लिकेशन हर बार एक्सएमएल का उत्सर्जन करेगा, लेकिन कभी-कभी इसे ब्राउज़रों के लिए एक्सएसएलटी के साथ बदल दें।

यदि आपके पास यह संबंध नहीं है, तो मुझे रेज़र पर XSLT का कोई लाभ दिखाई नहीं देता है। यह उन चिंताओं को अलग करता है जो रेजर भी प्रदान करता है। यह आपको HTML को वेबसाइट को फिर से खोलने की आवश्यकता के बिना संशोधित करने की अनुमति देता है, जिसे रेजर भी अनुमति देता है।

आपके द्वारा सूचीबद्ध लाभों के लिए:

XSLT एक मानक है और अभी भी भविष्य में कई वर्षों तक मौजूद रहेगा

क्या आप एक एप्लिकेशन बनाने की योजना बना रहे हैं जो बहुत लंबे समय तक जीवित रहेगा? रेजर का चार साल में उपयोग किए जाने की संभावना है, या कम से कम समर्थन किया जाना चाहिए। अधिकांश अनुप्रयोगों का जीवनकाल चार साल से कम है, इसलिए ...

गैर प्रोग्रामर के लिए इरेज़र (कुछ ऐसा जो मैं साथ लड़ सकता था)।

रुको क्या?! यहां तक ​​कि प्रोग्रामर पाते हैं कि XSLT बेकार है, समझना और उपयोग करना मुश्किल है। और जब मैं एक्सएमएल के बारे में गैर-प्रोग्रामर से बात करता हूं (एक्सएसएलटी के करीब भी नहीं), तो वे रोते हैं और भाग जाते हैं।

यह हमारी पिछली कुछ परियोजनाओं में सफल रहा है।

यदि आपकी टीम ने पहले कभी रेज़र का उपयोग नहीं किया है, तो इसे सीखने के लिए आवश्यक समय पर विचार करें।

यदि आपकी टीम ने इसका उपयोग किया है, लेकिन वे परियोजनाएं विफल रहीं, तो विश्लेषण करें कि यह विफल क्यों है और क्या यह रेजर के कारण था, और भविष्य की परियोजनाओं में ऐसी विफलताओं से बचने के लिए आप क्या कर सकते हैं।

Comments

मुझे यकीन नहीं है कि यह 1: 1 है कुछ पेज मर्ज किए गए कई xml मॉडल का उपयोग कर सकते हैं।

— डैनियल लिटिल

@Lavinski: संपादन देखें। मैंने 1: 1 और अन्य मामलों के बीच के अंतर को थोड़ा बेहतर बताने की कोशिश की। मुझे आशा है कि यह आपको यह देखने में मदद करता है कि कौन सा मामला आपकी विशिष्ट परियोजना का है।

— आर्सेनी मूरज़ेंको

आप क्यों कहते हैं कि रेजर 4 साल के लिए इस्तेमाल होने जा रहा है ?? इसके अलावा, एक साइड नोट के रूप में, मुझे लगता है कि 4 साल एक ऐप के जीवनकाल के लिए बहुत कम समय है और अगर मुझे ऐसी तकनीक का चयन करना है जो 4 साल के लिए समर्थित होगी, तो मैं क्विकस्टार्ट गाइड पढ़ने में भी परेशान नहीं होगा: डी

— बार्टोस

Answer 4

मेरी सिफारिश रेजर है और मुख्य कारण यह है कि एक्सएसएलटी के साथ (एक्सएसएलटी के पक्ष में और आपके तर्कहीन तर्क के विपरीत काम करना बहुत आसान है, हालांकि, आप मेरी तरफ हैं)। मेरे पास दोनों के साथ काम करने का अनुभव है और रेजर सशर्त बयानों में असाधारण रूप से शक्तिशाली हो जाता है, घोषणापत्र सहायक (प्रिंसिपल में कार्य), शाखा, लूपिंग, आदि।

आखिरकार, रेजर को मत भूलना एक प्रोग्रामिंग भाषा (हाँ, एक टेम्पलेट इंजन, या दृश्य इंजन है, लेकिन प्रोग्रामिंग भाषा के माध्यम से C # या VB.NET) के रूप में कार्यान्वित किया जाता है, जबकि XSLT में मार्कअप संरचना होती है।

मुझे लगता है कि आपका परिदृश्य एक जटिल व्यावसायिक अनुप्रयोग लिखने के लिए C # या T-SQL का चयन करने की कोशिश कर रहा है। जबकि T-SQL सेट ऑपरेशन में बहुत शक्तिशाली है, यह बस तब टूटता है जब आप इसमें तर्क (यदि-और, स्विच, के लिए, आदि) को लागू करने का प्रयास करते हैं।

Answer 5

आपको चुनने की आवश्यकता नहीं है, आप दोनों का उपयोग कर सकते हैं। ASP.NET MVC में आप एक ही समय में कई व्यू इंजन का उपयोग कर सकते हैं। वर्तमान में मैं जिस प्रोजेक्ट पर काम कर रहा हूं उसमें मैं XSLT का उपयोग आसानी से देखने और रूपों के लिए रेजर के लिए कर रहा हूं। आप XSLT का उपयोग रेज़र लेआउट या रेज़र के साथ XSLT लेआउट के साथ भी कर सकते हैं। मैं XSLT लेआउट का उपयोग कर रहा हूं, इसलिए मैं बस एक रेज़र लेआउट का उपयोग करता हूं जो XSLT लेआउट को कॉल करता है और एचटीएमएल को मापदंडों के रूप में पास करता है:

@{ 
   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 का उपयोग करना देखें ।

Answer 6

मेरा सुझाव है कि एक तीसरा और बेहतर तरीका है: एक एकल सेवा / एप्लिकेशन परत के ऊपर दो अलग-अलग पतले सामने के छोर रखें, जिनके पास कोई यूआई नहीं है।

इसलिए, इसके बजाय

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

उपयोग

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

और सुनिश्चित करें कि UI और सेवा में केवल वही कोड है जो उस इंटरफ़ेस के लिए अद्वितीय है। (ASCII डायग्राम के लिए माफी, सबसे अच्छा मैं अभी कर सकता हूं)

जिस कारण से मैं आपके द्वारा चर्चा की जा रही डिज़ाइनों के बारे में चिंतित हूं, वह यह है कि यह सेवा के विकास के लिए उपयोगकर्ता इंटरफ़ेस के विकास को जोड़ता है, जो शायद ही कभी आप कैसे काम करना चाहते हैं। यदि व्यवसाय उपयोगकर्ता इंटरफ़ेस में कार्यक्षमता का एक टुकड़ा जोड़ना चाहता है, तो आप इसे करने से पहले उस सेवा को लिखने के लिए मजबूर नहीं होना चाहते हैं। आप उपयोगकर्ता इंटरफ़ेस भाग लिखना चाहते हैं और फिर, यह मानते हुए कि यह सेवा में आवश्यक है, वहां कोड का पुन: उपयोग करें।

इससे भी बदतर, अगर व्यवसाय डेटा को एंड-यूज़र के लिए बहुत अलग तरीके से प्रदर्शित करना चाहता है कि यह सेवा के माध्यम से मैकेनिकल उपयोगकर्ता को कैसे प्रस्तुत किया जाता है (जो कि अत्यधिक संभावना है), तो आपको XSLT में जटिल कोड डालना शुरू करना होगा, या उपयोगकर्ता को प्रस्तुति का प्रतिनिधित्व करने के लिए आपकी सेवा के शीर्ष पर दूसरी सेवा परत (या बदतर, वसा नियंत्रक) का निर्माण करें।

इस मामले में सत्यापन के बारे में सोचें। आप संभावित रूप से विश्वास के तीन स्तरों को आकर्षित कर रहे हैं। आपके मॉडल को यह सुनिश्चित करने के लिए सत्यापन की आवश्यकता होगी कि आप अमान्य डेटा संग्रहीत नहीं करते हैं; तब आपकी सेवा को कुछ और सत्यापन की आवश्यकता हो सकती है, यह सुनिश्चित करने के लिए कि बाहरी उपभोक्ता ऐसा कुछ करने की कोशिश न करें जो उन्हें करने की अनुमति नहीं है; और आपके UI को कम से कम कुछ सत्यापन नियमों की आवश्यकता होगी, ताकि वह पोस्टबैक से बच सके।

और इससे पहले कि हम किसी ऐसी चीज़ की चिपचिपी स्थिति को भी छू लें जिसे एपीआई के माध्यम से अनुमति नहीं दी जानी चाहिए, लेकिन यूआई के माध्यम से अनुमति दी जानी चाहिए, जिसके लिए एपीआई की आवश्यकता होती है।

मैंने एक तर्क सुना है कि आपकी सेवा के माध्यम से आपका यूआई चलाना डॉगफूडिंग है और इस तरह सेवा की गुणवत्ता के लिए अच्छा है, लेकिन मैं दृढ़ता से सुझाव देता हूं कि सेवा के बीच चिंताओं को अलग करते हुए ठोस (और ठोस) रखते हुए बेहतर तरीके हैं। यूआई और व्यापार मॉडल।

यह सब कहा, अगर आप एक यूआई के साथ अपनी सेवा को लपेटने का तरीका जाना चाहिए, तो मैं दृढ़ता से XSLT पर रेजर की सिफारिश करूंगा।

XSLT एक मानक है, हाँ। लेकिन XSLT 2.0 के पास अभी भी सीमित समर्थन है, इसलिए यदि आप उस तर्क को बनाना चाहते हैं तो आप एक पुराने मानक के साथ फंस गए हैं।

XSLT को पढ़ना आसान नहीं है। किसी के द्वारा जो XSLT विशेषज्ञ नहीं है। आपको क्या लगता है कि नए कर्मचारियों को नियुक्त करने की आवश्यकता होने पर आपको ढूंढना आसान है? कोई XVCT विशेषज्ञ या MVC विशेषज्ञ के लिए ASP.NET होने का दावा कर रहा है?

और हाँ, मैंने XSLT को सफलतापूर्वक उपयोग करते देखा है, लेकिन ASP.NET के लिए MVC से पहले केवल एक विकल्प था।

Comments

प्रश्न में परतें वास्तव में अंतिम नहीं हैं, वे सिर्फ कुछ पृष्ठभूमि हैं, फोकस रेजर है।

— डैनियल लिटिल