Czy Razor lub XSLT jest lepszy dla mojego projektu? [Zamknięte]

Jestem na wczesnym etapie projektowania systemu, który zasadniczo zostanie podzielony na dwie części. Jedna część to usługa, a druga to interfejs z usługą dostarczającą dane poprzez coś takiego jak OData lub XML. Aplikacja będzie oparta na wzorze architektonicznym MVC. W przypadku widoków rozważamy użycie XSLT lub Razor w ASP.NET.

XSLT lub Razor pomogłyby w rozdzieleniu problemów, gdy oryginalny kod XML lub odpowiedź reprezentuje twój model, a XSLT lub „widok Razor” reprezentuje twój widok. W tym przykładzie pomijam kontroler. Wstępna propozycja projektu zaleca XSLT, jednak zasugerowałem użycie Razor zamiast bardziej przyjaznego silnika widoku.

Oto powody, dla których zasugerowałem Razor (C #):

• Łatwiejsza praca i tworzenie bardziej skomplikowanych stron.
• Może łatwo wytwarzać dane wyjściowe inne niż * ML, np. Csv, txt, fdf
• Mniej pełnych szablonów
• Model widoku jest silnie typowany, przy czym XSLT musiałby polegać na konwencji, np. Wartości logicznej lub wartości daty
• Znaczniki są bardziej dostępne, np. Nbsp, normalizacja nowej linii, normalizacja wartości atrybutu, reguły białych znaków
• Wbudowany pomocnik HTML może generować kod sprawdzania poprawności JS na podstawie atrybutów DTO
• Wbudowany pomocnik HTML może generować linki do akcji

Argumenty za XSLT nad brzytwą były następujące:

• XSLT jest standardem i będzie istniał jeszcze wiele lat w przyszłości.
• Trudno jest przypadkowo przenieść logikę do widoku
• Easer dla programistów (z którymi się nie zgadzam).
• Odniósł sukces w niektórych z naszych poprzednich projektów.
• Wartości danych są domyślnie zakodowane w formacie HTML
• Zawsze dobrze wykształcony

Więc szukam agumentów po obu stronach, rekomendacji lub innego doświadczenia dokonującego podobnego wyboru?

I HAVE powodzeniem stosowany XSLT jako warstwy prezentacji internetowej ... w roku 1999. W ciągu ostatnich 12 lat, znacznie lepsze opcje mają przyjść. Zrób sobie wielką przysługę i użyj Razor. To przyjemność.

Oto podstawowe porównanie składni

Brzytwa

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

Źródła danych dla dwóch przykładów

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>

DO#

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

Czy istnieje relacja 1: 1 między stronami HTML a danymi wyjściowymi XML? Rozważ następujące przypadki:

• Silna korelacja: każda strona internetowa ma kod HTML i odpowiedni formularz XML.

Przykład: prowadzisz witrynę z recenzjami filmów. Masz stronę główną z najnowszymi recenzjami, jedną stronę na recenzję oraz stronę z komentarzami i ocenami gości. Brak jakiejkolwiek rejestracji. Chcesz ułatwić programowe korzystanie z witryny bez brzydkiej analizy HTML. W tym przypadku możesz mieć stosunek 1: 1: wszystko, co człowiek może zrobić, bot może również: przy tych samych żądaniach uzyskają tę samą treść.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau jest używany przez ludzi.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml jest wykorzystywany przez boty do uzyskiwania dostępu do tych samych informacji.

• Słaba korelacja lub jej brak: po jednej stronie jest tylko kilka usług internetowych, a po drugiej - kilka stron internetowych.

Przykład: jesteś twórcą innego Facebooka. Istnieje strona internetowa i interfejs API. Jedynym wspólnym punktem jest to, że używana jest ta sama baza danych, ale boty nie mają dostępu do tego, co ludzie mogą, a informacje są prezentowane inaczej.

http://example.com/MyFriends/ pokazuje dziesięciu najlepszych znajomych, których mam na koncie. Kliknięcie „Więcej” powoduje wysłanie żądania AJAX, pokazującego innych przyjaciół.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml pokazuje odpowiedni kod XML ze wszystkimi znajomymi, których mam.

Możesz to zobaczyć:

• Interfejs API jest hostowany osobno, na odrębnym serwerze,
• Relacja między stronami a interfejsem API jest trudna do zauważenia.
• Witryna musi używać sesji do śledzenia logowania. Interfejs API potrzebuje tylko wygenerowanego klucza, aby był wysyłany przy każdym żądaniu.
• Liczba żądań nie jest taka sama. W jednym przypadku musisz wysłać zapytanie do strony, a następnie wykonać żądanie AJAX, aby uzyskać resztę znajomych. W innym przypadku możesz uzyskać całą listę na raz.
• Zwrócone informacje nie są takie same. Jako człowiek identyfikujesz znajomych po imieniu. Bot korzystający z interfejsu API zidentyfikuje je na podstawie unikalnego identyfikatora, którego nigdy nie zobaczysz na stronie.

Polecam wybór XSLT tylko wtedy, gdy jesteś blisko relacji 1: 1 . W takim przypadku uprości to podejście: aplikacja będzie emitować XML za każdym razem, ale czasami przekształci go za pomocą XSLT dla przeglądarek.

Jeśli nie masz tej relacji, nie widzę żadnej przewagi XSLT nad Razor. Zapewnia oddzielenie problemów, które zapewnia Razor. Pozwala modyfikować HTML bez konieczności ponownej kompilacji strony internetowej, na co pozwala Razor.

Jeśli chodzi o wymienione korzyści:

XSLT jest standardem i będzie istniał jeszcze wiele lat w przyszłości

Czy planujesz stworzyć aplikację, która będzie działać przez bardzo długi czas? Maszynki do golenia mają szansę być używane za cztery lata lub przynajmniej uzyskać wsparcie. Żywotność większości aplikacji wynosi mniej niż cztery lata, więc ...

Easer dla nie-programistów (coś, z czym mógłbym się zmagać).

Czekaj, co?! Nawet programiści uważają, że XSLT jest do bani, jest trudny do zrozumienia i użycia. A kiedy rozmawiam z nie-programistami o XML (nawet nie w pobliżu XSLT), płaczą i uciekają.

Odniósł sukces w niektórych z naszych poprzednich projektów.

Jeśli Twój zespół nigdy wcześniej nie używał Razor, zastanów się, ile czasu potrzeba, aby się go nauczyć.

Jeśli Twój zespół go wykorzystał, ale te projekty zakończyły się niepowodzeniem, zastanów się nad analizą, dlaczego nie powiodło się to z powodu Razor i co możesz zrobić, aby uniknąć takich awarii w przyszłych projektach.

Moje zalecenie to Razor, a głównym powodem jest to, że o wiele łatwiej jest z nim pracować (niż XSLT, i w przeciwieństwie do twojego wyliczonego argumentu na korzyść XSLT, jednak jesteś po mojej stronie). Mam doświadczenie w pracy z nimi i Razor staje się wyjątkowo potężny w instrukcjach warunkowych, deklaratywnych pomocnikach (funkcje główne), rozgałęzianiu, zapętlaniu itp.

W końcu nie zapominajmy, że Razor to język programowania (tak, silnik szablonów lub silnik przeglądania, ale zaimplementowany za pomocą języka programowania, takiego jak C # lub VB.NET), podczas gdy XSLT ma bardziej strukturę znaczników.

Myślę, że twój scenariusz przypomina próbę wybrania C # lub T-SQL do napisania złożonej aplikacji biznesowej. Podczas gdy T-SQL jest dość potężny w ustawianych operacjach, po prostu psuje się, gdy próbujesz zaimplementować w nim logikę (jeśli-inaczej, przełącznik, for itp.).

Nie musisz wybierać, możesz użyć obu. W ASP.NET MVC można używać wielu mechanizmów przeglądania jednocześnie. W projekcie, nad którym obecnie pracuję, używam XSLT dla widoków tylko do odczytu i Razor dla formularzy. Możesz także użyć XSLT z układem Razor lub Razor z układem XSLT. Używam układu XSLT, więc po prostu używam układu Razor, który wywołuje układ XSLT i przekazuje sekcje HTML jako parametry:

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

... a w htmlRaw.xsltobie po prostu użyj disable-output-escaping="yes":

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

Zobacz Korzystanie z Razor i XSLT w tym samym projekcie .

Sugerowałbym, że istnieje trzeci i lepszy sposób: umieść dwa różne cienkie interfejsy na jednej warstwie usługi / aplikacji, która nie ma interfejsu użytkownika jako takiego.

Więc raczej niż

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

posługiwać się

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

i upewnij się, że interfejs użytkownika i usługa zawierają TYLKO kod, który jest unikalny dla tego interfejsu. (przepraszam za diagramy ASCII, najlepiej, co mogę teraz zrobić)

Powodem, dla którego martwiłbym się którykolwiek z omawianych projektów, jest to, że wiąże on rozwój interfejsu użytkownika z rozwojem usługi, co rzadko jest sposobem pracy. Jeśli firma chce dodać funkcjonalność do interfejsu użytkownika, nie musisz być zmuszany do napisania tej usługi, zanim będzie to możliwe. Chcesz napisać część interfejsu użytkownika, a następnie, zakładając, że jest to wymagane w usłudze, ponownie użyj tam kodu.

Co gorsza, jeśli firma chce wyświetlać dane w sposób bardzo odmienny dla użytkownika końcowego niż sposób, w jaki są one przedstawiane mechanicznemu użytkownikowi za pośrednictwem usługi (co wydaje się wysoce prawdopodobne), będziesz musiał zacząć umieszczać złożony kod w XSLT lub zbuduj drugą warstwę usługi (lub, co gorsza, kontrolery tłuszczu) na swojej usłudze, aby reprezentować prezentację dla użytkownika.

Pomyśl o sprawdzeniu poprawności w tym przypadku. Potencjalnie czerpiesz trzy poziomy zaufania. Twój model będzie wymagał walidacji, aby upewnić się, że nie przechowujesz nieprawidłowych danych; wtedy Twoja usługa może wymagać dodatkowej weryfikacji, aby upewnić się, że zewnętrzni konsumenci nie próbują robić czegoś, na co nie mają pozwolenia; a Twój interfejs użytkownika będzie wymagał, w najlepszym wypadku, kilku reguł sprawdzania poprawności, aby uniknąć postback.

I to zanim jeszcze dotkniemy lepkiej sytuacji czegoś, co nie powinno być dozwolone przez interfejs API, ale powinno być dozwolone przez interfejs użytkownika, który wymaga interfejsu API.

Słyszałem argument, że uruchamianie interfejsu użytkownika za pośrednictwem usługi to karma dla psów, a zatem dobre dla jakości usługi, ale zdecydowanie sugeruję, że istnieją lepsze sposoby na to, zachowując jednocześnie solidne (i SOLIDNE) rozdzielenie obaw między usługami, interfejs użytkownika i model biznesowy.

Wszystko to powiedziało, że jeśli musisz przejść do owijania swojej usługi interfejsem użytkownika, zdecydowanie polecam Razor zamiast XSLT.

XSLT to standard, tak. Ale XSLT 2.0 nadal ma ograniczone wsparcie, więc utkniesz z przestarzałym standardem, jeśli chcesz wysunąć ten argument.

XSLT nie jest łatwy do odczytania. Każdy, kto nie jest ekspertem XSLT. Jak myślisz, kogo łatwiej znaleźć, kiedy potrzebujesz zatrudnić nowego personelu? Czy ktoś twierdzi, że jest ekspertem XSLT lub ekspertem ASP.NET for MVC?

I tak, widziałem, że XSLT jest z powodzeniem używany, ale dopiero przed MVC dla ASP.NET było opcją.