"http://example.com/whateverpath"사용자 지정 HttpHandler에 의해 요청을 처리하지만 "whateverpath"값에 따라 반환되는 것들이 필요합니다.asp.net 사용자 지정 HttpHandler 및 URL 라우팅
그래서 "http://example.com/path1"에 액세스하는 사용자는 "http://example.com/path2"에 액세스하는 사용자와 다른 응답을 얻지 만 두 요청은 모두 동일한 HttpHandler에서 처리해야합니다. 아이디어는 데이터베이스에서 "whateverpath"를 찾고 결과에 따라 응답 내용을 반환합니다.
URL 라우팅에 대해 듣고 이미 사용자 지정 HTTP 처리기가 작동하지만 두 기술을 결합하여 필요한 것을 얻을 수 있습니까?
이 문제와 관련하여 의견을 보내 주시면 감사하겠습니다.
건배 프랭크 아벨은
당신이 IHttpHandler를 구현하는 클래스가 호출이 : MyHandler과 네임 스페이스 Example에, 당신은에서 다음과 같이 설정하는 데 필요한 httpHandlers 섹션에서 Web.Config 사이트의이 이후
<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
</httpHandlers>
모든 URL을 리디렉션 귀하의 웹 사이트/응용 프로그램에 대한 귀하의 처리기에 정적 콘텐츠 (imgs, 스크립트, 스타일 시트 등)를 제공하는 방법을 고려해야합니다.
<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
<add verb="GET,HEAD" path="static/*" type="System.Web.StaticFileHandler" />
</httpHandlers>
을 (비주얼 스튜디오에 포함) 지역 dev에 웹 서버의 경우이 모든 것을 필요한 것입니다 : 한 가지 방법은 다음과 같은 당신의 핸들러를 설정할 수 있습니다 http://example.com/static/...처럼 일관된 URL에서 정적 컨텐츠를 저장하는 것입니다. IIS의 경우 IIS가 이러한 URL을 처리하는 방법을 알려줘야합니다 (서버가 먼저 ASP.NET으로 보낼지 또는 다른 확장 프로그램으로 보낼지 여부를 결정하라는 요청을 먼저 분석하기 때문에).
지금 IIS 및 ASP.NET 모두가 당신의 URL을 처리하는 방법을 알고있다>
위의 접근 방식은 정적 파일을 요청할 때 ASP.NET이 IIS가 아닌 파일을 실제로 제공한다는 것을 의미하므로 몇 가지 단점이 있습니다 (논의 된 내용은 here). 디렉터리를 응용 프로그램 (IIS 관리자)으로 전환하고 와일드 카드 매핑 문 (위에 추가)을 제거한 다음 응용 프로그램에서 다시 전환하여이 동작 (정적 디렉터리에서 와일드 카드 매핑을 사용하지 않도록 설정)을 무시할 수 있습니다. 정적 파일은 ASP.NET을 불쾌하게하지 않고 IIS에서 처리합니다.
나는 URL 라우팅 및 HTTP 처리기를 결합하지 않는 것이 좋습니다.
URL 라우팅에있어 완벽한 작업입니다. 그러나, 나는 그것을 위해 HTTP 처리기를 사용하지 않을 것이다.
단순히 "~/CustomData/whateverpath"를 ASPX 페이지에 매핑하십시오. 그런 다음 페이지가 데이터베이스에서 데이터를로드하게합니다. "모든 경로"가 무엇이든 관계없이 데이터를 조회하는 논리가 동일하면 모든 변형에 대해 논리를 반복하지 않아도됩니다. 대신 모든 경우에 대해 올바른 데이터를로드하는 단일 파일에이 파일을 매핑하려고합니다.
HTTP 처리기는 완전히 다른 문제이므로이 용도로 사용하면 안됩니다. (BTW, 방금 HTTP 처리기에 대한 기사를 게시했으며 http://www.blackbeltcoder.com/Articles/asp/writing-a-custom-http-handler-in-asp-net에서 볼 수 있습니다.) 그래서
먼저 Jonathan Wood의 이전 게시물에 동의합니다. HttpHandler에서 라우팅을 사용하는 것은 좋은 생각이 아닙니다. 그러나 나는 그가 거기에 라우팅 표준 MVC를 언급했다 꽤 확신합니다.
좋은 방법은 맞춤 라우팅을 사용하는 것입니다. 그것에 대한 기사를 게시했습니다. - Basic Routing for HttpHandler
"HTTP 처리기를 사용하지 않겠습니까?" 지금까지 HTTP 처리기가 정상적인 ASPX 페이지보다 더 나은 성능을 제공한다는 것을 알고 있으며 HTTP 처리기의 단점을 보지 못했습니다. –
페이지 라우팅은보다 직관적이며 유연성을 제공합니다. 그것은 당신이 묘사 한 것과 똑같이 디자인되었습니다. HTTP 처리기가 더 빨라질 수도 있지만 ASP.NET 페이지 지원의 일부가 실행 /로드되지 않기 때문입니다. 방금 사용자 지정 HTTP 처리기를 구현했습니다. 그것은 위대한 작품. 그러나 나는 그것이 당신이 묘사 한 것에 대한 올바른 접근법이라고 생각하지 않습니다. –
답장을 보내 주셔서 감사합니다 ... "곧장 앞으로 나아가보다 융통성있게"무엇을 의미하는지 자세히 설명해 주시겠습니까? HTTP 처리기가 매우 쉽고 간단하게 접근하는 것을 볼 수 있습니다. 그 외에도 URL 라우팅 솔루션의 모습이 구체적 일 수 있습니까? Rudu는 그의 대답에 정말 자세히 설명되었습니다. Jonathan에게 다시 한번 감사드립니다. –