표준 컨트롤러/Ioc/리포지토리/UoW를 사용하여 MVC 사용 Consumer With Architecture

Question

JavaScript로 WebAPI ODATA 서비스를 사용하는 것은 문제가되지 않지만 ... http 호출 (CRUD)을 래핑하는 현재 권장 사항은 무엇입니까? 저장소로 MVC5 응용 프로그램을 통해 소비 될 수 있습니다. 궁극적으로 볼 수있는 대부분의 지침은 엔티티/dbcontext에 직접 전달됩니다. 나는 "자신의 Kool-Aid를 마시는 것"을 보여주고 응용 프로그램의 소비자에게 외부 적으로 공개되는 동일한 ODATA (일반 WebAPI 일 수도 있음)를 사용하는 지침을 찾고 있습니다. 내 마음에

, 나는 흐름의 이런 종류 찾고 있어요 : 의 AppController (사이트 1 : 443) -> AppRepository -> OdataController (apiSite2 : 443) -> OdataRepository -> 데이터 소스

부차적 인 관심사는 모든 소비자가 데이터 소스에 직접 액세스하고 싶지 않다는 것입니다. 특히 승인되지 않은 게시물은 컨트롤러에있는 모든 로직을 원하지 않습니다. 내가 뭔가를 overthinking 수도 ...

Answer 1

나는 일반적으로 컨트롤러에서 비즈니스 로직을 추출하기 위해서도 가능하면 로직을 도메인 객체로 푸시한다. 그렇게 할 수 없다면 문제의 논리를 관리하도록 특별히 고안된 클래스 (예 : 두 개의 서로 다른 객체 간의 상호 작용)를 만듭니다.

다른 모든 것이 실패하면 서비스에 의해 관리되는 상호 작용을 갖게됩니다. 클래스는 다음과 같을 수 있습니다.

public class SomeApiController : ApiController 
{ 
    public SomeApiController(ISomeApiService service) 
    { 
     this.Service = service; 
    } 

    private ISomeApiService Service { get; set; } 

    public IHttpActionResult SomeMethod(int someObjectId) 
    { 
     // service manages the logic and either defers to the object in question or resolves it through some specialized class 
     var result = this.Service.SomeMethod(someObjectId); 
     return this.OK(result); 
    } 
} 

public class SomeApiService : ISomeApiService 
{ 
    public SomeApiService(ISomeRepository repository) 
    { 
     this.Repository = repository; 
    } 

    private ISomeRepository Repository { get; set; } 
} 

... 등등.

레이어는 서로에 대한 의존성이 없으므로 원하는 IoC 컨테이너를 통해 확인할 수없고 종속성이 한 방향으로 만 이동한다는 아이디어가 있습니다. 즉, SomeApiService는 SomeApiController에 종속성이 없으며 SomeApiRepository는 SomeApiService에 종속되지 않습니다.