Razor 또는 XSLT가 프로젝트에 더 좋습니까? [닫은]

필자는 본질적으로 두 부분으로 나눌 시스템 설계의 초기 단계에 있습니다. 한 부분은 서비스이고 다른 부분은 OData 또는 XML과 같은 것을 통해 데이터를 제공하는 서비스와의 인터페이스입니다. 응용 프로그램은 MVC 아키텍처 패턴을 기반으로합니다. 보기를 위해 ASP.NET에서 XSLT 또는 Razor를 사용하는 것을 고려하고 있습니다.

XSLT 또는 Razor 는 원본 XML 또는 응답이 모델을 나타내는 경우 XSLT 또는 'Razor view'가 사용자의 뷰를 나타내는 문제를 분리하는 데 도움이됩니다. 이 예제에서는 컨트롤러를 그대로 두겠습니다. 초기 설계 제안은 XSLT를 권장하지만 Razor를보다 친숙한보기 엔진으로 사용하는 것이 좋습니다.

Razor (C #)에 제안한 이유는 다음과 같습니다.

• 보다 복잡한 페이지로 작업하고 더 쉽게 만들 수 있습니다.
• csv, txt, fdf와 같이 비 * ML 출력을 쉽게 생성 할 수 있습니다
• 덜 장황한 템플릿
• 뷰 모델은 XSLT가 규칙 (예 : 부울 또는 날짜 값)에 의존해야하는 강력한 유형입니다.
• nbsp, 줄 바꿈 정규화, 속성 값 정규화, 공백 규칙과 같은 마크 업에보다 접근하기 쉽습니다.
• 기본 제공 HTML 도우미는 DTO 속성을 기반으로 JS 유효성 검사 코드를 생성 할 수 있습니다.
• 내장 HTML 도우미는 작업에 대한 링크를 생성 할 수 있습니다

그리고 면도칼에 대한 XSLT의 주장은 다음과 같습니다.

• XSLT는 표준이며 앞으로도 수년 동안 존재할 것입니다.
• 실수로 로직을 뷰로 옮기기가 어렵습니다.
• 프로그래머가 아닌 사람들을 위해 쉬움 (나는 동의하지 않음).
• 지난 프로젝트 중 일부에서 성공했습니다.
• 데이터 값은 기본적으로 HTML로 인코딩됩니다
• 항상 잘 형성

그래서 나는 어느 쪽의 주장, 권장 사항 또는 비슷한 선택을 한 경험을 찾고 있습니까?

나는 하신 성공적으로 지난 12 년에서 1999 년에 ... 웹 프리젠 테이션 계층으로 XSLT를 사용, 더 나은 옵션이 따라왔다. 자신에게 큰 호의를 베풀고 면도기를 사용하십시오. 그것은 기쁨.

기본 구문 비교는 다음과 같습니다.

면도칼

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

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 을 사용하여 동일한 정보에 액세스합니다.

• 약하거나 상관없는 관계 : 한쪽에는 웹 서비스가 많고 다른쪽에는 웹 페이지가 많이 있습니다.

예 : 당신은 다른 Facebook의 제작자입니다. 웹 사이트가 있고 API가 있습니다. 유일한 공통점은 동일한 데이터베이스가 사용되지만 봇은 사람들이 할 수있는 것에 액세스 할 수 없으며 정보가 다르게 표시된다는 것입니다.

http://example.com/MyFriends/ 는 내 계정에있는 10 명의 친구를 보여줍니다. "추가"를 클릭하면 AJAX 요청이 작성되어 다른 친구를 보여줍니다.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml 은 내가 가진 모든 친구들과 해당 XML을 보여줍니다.

당신은 그것을 볼 수 있습니다 :

• API는 별도의 서버에서 별도로 호스팅됩니다.
• 페이지와 API의 관계는 잘 보이지 않습니다.
• 웹 사이트는 세션을 사용하여 로그온을 추적해야합니다. API는 모든 요청에 ​​대해 생성 된 키만 보내면됩니다.
• 요청 수가 동일하지 않습니다. 어떤 경우에는 페이지를 쿼리 한 다음 AJAX 요청을 수행하여 나머지 친구를 확보해야합니다. 다른 경우에는 전체 목록을 한 번에 얻습니다.
• 반환 된 정보가 동일하지 않습니다. 인간은 친구의 이름으로 친구를 식별합니다. API를 사용하는 봇은 웹 사이트에서는 볼 수없는 고유 식별자로 식별합니다.

1 : 1 관계에 가까운 경우에만 XSLT를 선택하는 것이 좋습니다 . 이 경우 접근 방식이 간소화됩니다. 응용 프로그램은 매번 XML을 내보내지만 때로는 브라우저의 XSLT로 변환합니다.

이 관계가 없으면 Razor에 비해 XSLT의 이점이 없습니다. Razor가 제공하는 우려 ​​사항도 분리합니다. Razor가 허용하는 웹 사이트를 다시 컴파일하지 않고도 HTML을 수정할 수 있습니다.

귀하가 기재 한 혜택에 관해서는 :

XSLT는 표준이며 향후 몇 년 동안 계속 존재합니다

당신은 매우 오랫동안 살 것이다 응용 프로그램을 만들 계획입니까? 면도기는 4 년 안에 사용되거나 최소한 지원을받을 기회가 있습니다. 대부분의 응용 프로그램의 수명은 4 년 미만입니다.

프로그래머가 아닌 사람들을 위해 쉬움 (내가 싸울 수있는 것).

무엇을 기다립니다?! 프로그래머조차도 XSLT가 짜증나고 이해하고 사용하기 어렵다는 것을 알게됩니다. 그리고 프로그래머가 아닌 사람들에게 XML에 대해 이야기 할 때 (XSLT에 가깝지 않음) 그들은 울고 도망칩니다.

지난 프로젝트 중 일부에서 성공했습니다.

팀에서 Razor를 사용한 적이 없다면 배우는 데 필요한 시간을 고려하십시오.

팀에서 사용했지만 해당 프로젝트가 실패한 경우 Razor로 인해 실패한 이유와 실패한 이유 및 향후 프로젝트에서 이러한 실패를 피하기 위해 무엇을 할 수 있는지 분석하십시오.

내 권장 사항은 면도기 이며 주된 이유는 XSLT보다 작업하기가 훨씬 쉬우 며 XSLT에 찬성하여 열거 된 주장과 반대이지만 내 편입니다. 나는 둘 다와 함께 일한 경험이 있으며 Razor는 조건문, 선언적 도우미 (주로 기능), 분기, 반복 등에서 매우 강력합니다.

결국 Razor는 프로그래밍 언어 (예 : 템플릿 엔진 또는 뷰 엔진이지만 C # 또는 VB.NET과 같은 프로그래밍 언어를 통해 구현 됨) 인 반면 XSLT는 더 많은 마크 업 구조를 갖습니다.

귀하의 시나리오는 복잡한 비즈니스 응용 프로그램을 작성하기 위해 C # 또는 T-SQL을 선택하는 것과 같습니다. T-SQL은 집합 작업에서 매우 강력하지만 논리 (if-else, switch, for 등)를 구현하려고하면 중단됩니다.

선택할 필요가 없으며 둘 다 사용할 수 있습니다. ASP.NET MVC에서는 여러 뷰 엔진을 동시에 사용할 수 있습니다. 현재 작업중 인 프로젝트에서 읽기 전용보기에는 XSLT를 사용하고 양식에는 면도기를 사용하고 있습니다. XSLT를 Razor 레이아웃과 함께 또는 Razor를 XSLT 레이아웃과 함께 사용할 수도 있습니다. XSLT 레이아웃을 사용하고 있으므로 XSLT 레이아웃을 호출하고 섹션 HTML을 매개 변수로 전달하는 Razor 레이아웃을 사용합니다.

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

동일한 프로젝트에서 Razor 및 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를 통해 허용되지 않아야하지만 API를 필요로하는 UI를 통해 허용되어야하는 무언가의 끈적한 상황을 만지기 전에입니다.

서비스를 통해 UI를 실행하는 것이 개밥이므로 서비스 품질에 좋다는 주장을 들었지만 서비스 간 문제를 견고하게 (그리고 SOLID) 분리하면서 유지하는 것이 더 좋습니다. UI와 비즈니스 모델.

UI로 서비스를 포장 해야하는 경우 XSLT보다 Razor를 강력히 권장합니다.

XSLT는 표준입니다. 그러나 XSLT 2.0은 여전히 ​​지원이 제한되어 있기 때문에 그 주장을하고 싶다면 구식 표준을 고수해야합니다.

XSLT는 읽기 쉽지 않습니다. XSLT 전문가가 아닌 사람이 새로운 직원을 고용해야 할 때 누가 찾기가 더 쉽다고 생각하십니까? XSLT 전문가 또는 MVC 전문가를위한 ASP.NET이라고 주장하는 사람이 있습니까?

그리고 예, XSLT가 성공적으로 사용되는 것을 보았지만 ASP.NET 용 MVC가 옵션이되기 전에 만 가능했습니다.