나는 새로운 MVC4 프로젝트를 만들고 있으며, 연구 결과 자바 스크립트에서 서버 측으로의 통신이 컨트롤러 작업이 아닌 웹 API 프레임 워크를 통해 더 잘 이루어 졌다고 믿게되었습니다. 내 이해가 맞습니까?
나는 웹 API와 MVC 컨트롤러 사이에서 내 모든 속성 등을 공유 할 수 있다고 가정하고 있기 때문에 얼굴에는 큰 변화가 아닌 것 같습니다.
응용 프로그램을 설정할 때 구성 요소를 프로젝트로 분할하는 것을 좋아합니다. 내 계획은 MVC 프로젝트와 웹 API 프로젝트를 갖는 것이 었습니다. 그러나 나는 문제에 부딪쳤다. 예를 들어 나는 2 개의 앱, 별도의 라우팅 설정 등으로 끝났습니다.
그래서 내 질문은 MVC 응용 프로그램에서 웹 API 프레임 워크가 동일한 프로젝트 내에 있어야합니까, 아니면 웹 API가 자체 프로젝트로 분리되어 문제를 해결해야합니까?
답변:
불행히도 당신은 그것에 대해 틀 렸습니다- 나는 웹 API와 mvc 컨트롤러 사이에 내 모든 속성 등을 공유 할 수 있다고 생각하고 있습니다.
웹 API와 MVC에서 사용하는 많은 개념은 언뜻보기에는 비슷하지만 실제로는 호환되지 않습니다. 예를 들어, 웹 API 속성은 System.Web.Http.Filters.Filter이고 MVC 속성은 System.Web.Mvc.Filter-이며 상호 교환 할 수 없습니다.
모델 바인딩 (완전히 다른 메커니즘), 경로 (웹 API는 둘 다 동일한 기본 RouteTable에서 작동하더라도 경로가 아닌 HTTPRoutes를 사용함), 종속성 해결 자 (호환되지 않음) 등 많은 다른 개념에도 동일하게 적용됩니다. 표면은 실제로 매우 다릅니다. 또한 Web API에는 영역 개념이 없습니다.
궁극적으로 달성하려는 모든 것이 JSON 콘텐츠를 제공하는 "새롭고 트렌디 한"방법을 갖는 것이라면 해당 경로를 따르기 전에 두 번 생각하십시오. HTTP를 수용하고 RESTful 방식으로 앱을 빌드하는 것을 고려하지 않는 한 기존 코드를 리팩토링하지 않는 것이 좋습니다.
그것은 모두 당신이 무엇을 만들고 있는지에 달려 있습니다. 새 프로젝트를 시작할 때 필요한 것은 웹 앱을 용이하게하기 위해 JSON을 제공하는 것뿐입니다. (위에서 언급 한 것과 같은) 잠재적으로 중복되는 코드로 기꺼이 살 수 있다면 Web API는 내에서 쉽게 호스팅 될 수 있습니다. ASP.NET MVC와 동일한 프로젝트입니다.
온라인 서비스를위한 적절한 API를 구축하려는 경우에만 웹 API를 별도의 프로젝트로 분리 할 것입니다.
IMO, 보안 및 배포가 결정을 주도해야합니다. 예를 들어 MVC 앱이 양식 인증을 사용하지만 API에 대해 기본 인증 (SSL 포함)을 사용하는 데 관심이있는 경우 별도의 프로젝트로 작업이 더 쉬워집니다. www.example.com에서 사이트를 호스팅하고 싶지만 API를 api.example.com (vs. www.example.com/api)으로 호스팅하고 싶다면 별도의 프로젝트를 사용하면 삶이 더 쉬워집니다. 프로젝트를 분리하고 그에 따라 하위 도메인을 지정하고 MVC 앱에서 자체 API를 활용하려는 경우 API에 대한 클라이언트 측 호출에 대해 동일한 출처 정책 문제 를 처리하는 방법을 파악 해야합니다. 이에 대한 일반적인 해결책은 jsonp 또는 CORS 를 활용 하는 것입니다 (가능하면 가능할 경우).
업데이트 (2013 년 3 월 26 일) : 공식 CORS 지원 예정 : http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
어느 정도의 경험 후 (앱 및 mvc 용 API 생성). 나는 주로 둘 다합니다.
다른 클라이언트 또는 다른 장치 (Android / IOS 앱)에서 오는 API 호출에 대해 별도의 프로젝트를 만듭니다. 그 이유 중 하나는 인증이 다르기 때문에 토큰 기반 (상태 비 저장 유지)입니다. 내 MVC 응용 프로그램 내에서 이것을 혼합하고 싶지 않습니다.
내 mvc 애플리케이션에 대한 javascript / jquery api 호출의 경우 MVC 애플리케이션에 웹 API를 포함하도록 단순하게 유지하고 싶습니다. 동일한 응용 프로그램에 있기 때문에 Javascript API 호출로 토큰 기반 인증을 사용하지 않으려 고합니다. [authorize]API 끝점에서 속성을 사용할 수 있습니다 . 사용자가 로그인하지 않으면 데이터를 얻지 못합니다.
또한 쇼핑 카트를 처리하고 사용자 쇼핑 카트를 세션 (로그인하지 않은 상태)에 저장하려는 경우 자바 스크립트 코드를 통해 제품을 추가 / 삭제하는 경우에도 API에이를 포함해야합니다. 이렇게하면 API 상태 저장이 확실해 지지만 MVC-API의 복잡성도 줄어 듭니다.
SimpleInjector (IoC 프레임 워크)의 Steven은 두 개의 개별 프로젝트에 조언합니다. WebAPI에서 DependencyResolver.SetResolver와 HttpConfiguration.DependencyResolver의 차이점은 무엇입니까?
최근에 거의 동일한 작업을 수행했습니다. VS2012에서 웹 API 템플릿을 선택하는 새로운 MVC 4 웹 응용 프로그램 프로젝트로 시작했습니다.
이렇게하면 MVC와 동일한 애플리케이션에서 호스팅되는 웹 API가 생성됩니다.
ApiController를 별도의 클래스 라이브러리 프로젝트로 옮기고 싶었습니다. 이것은 상당히 쉬웠지만 해결책은 약간 숨겨져있었습니다.
MVC 4 프로젝트의 AssemblyInfo.cs에서 유사한 코드 줄을 추가합니다.
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
이제 LibraryRegistrator 클래스가 필요합니다.
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
MVC 4 프로젝트에서 Api 라이브러리에 대한 참조도 추가합니다.
이제 별도의 클래스 라이브러리 (yourown.dll)에 Api 컨트롤러를 추가 할 수 있습니다.
프로젝트가 두 개의 "프론트 엔드"를 보장 할 정도로 복잡하더라도 마지막 수단으로 webapi를 별도의 프로젝트로 분할하는 것만 고려할 것입니다. 배포 문제가 발생하고 초보자가 솔루션의 구조를 이해하기 어려울 것입니다. 라우팅 문제는 말할 것도 없습니다.
나는 하나의 "프레젠테이션 레이어"에서 격리 된 system.web 네임 스페이스를 유지하는 것을 목표로합니다. webapi가 프리젠 테이션 이 아니더라도 여전히 애플리케이션 인터페이스의 일부입니다. 컨트롤러가 아닌 도메인에 논리를 유지하는 한 너무 많은 문제가 발생하지 않아야합니다. 또한 Areas를 사용하는 것을 잊지 마십시오.
Web.Api에 대해 별도의 DLL을 설정하는 것 외에도.
제안 :
app_start시 호출 할 클래스 메소드 생성
[어셈블리 : WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Start")]
[assembly : WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "종료")]
Start 메서드 내에 web.api 경로 등록
public static void Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }
프로젝트를 웹 프로젝트에 참조하십시오. 시작 방법을 활성화합니다.
도움이 되었기를 바랍니다.