오늘 MVC 애플리케이션에 대해 열띤 토론을했습니다. 우리는 MVC ( ASP.NET )로 작성된 웹 사이트를 가지고 있으며 일반적으로보기에서 무언가의 패턴을 따릅니다.-> 컨트롤러를칩니다. 컨트롤러 방법 자체)-> 모델보기-> 헹굼 및 반복.
그는 우리 코드가 너무 밀접하게 결합되어 있다고 말했다. 예를 들어 데스크톱 응용 프로그램을 원한다면 기존 코드를 사용할 수 없습니다.
그가 말한 솔루션과 모범 사례는 API를 구축 한 다음 API를 기반으로 웹 사이트를 구축 한 다음 데스크톱 애플리케이션, 모바일 앱 등을 구축하는 것은 매우 간단합니다.
이것은 여러 가지 이유로 나에게 나쁜 생각처럼 보입니다.
어쨌든 나는이 연습을 논의 할 수있는 인터넷 검색으로 아무것도 찾을 수없는 것 같습니다. 누구나 장단점, 왜 해야하는지, 왜 더 이상 읽지 말아야하는지에 대한 정보가 있습니까?
나는 그것이 나쁜 생각이라고 생각하는 몇 가지 이유 :
백엔드를 API에서 실행하기에는 너무 추상적입니다. 당신은 그것을 너무 유연하게 만들어서 다루기 어려운 혼란을 만들려고합니다.
MVC에 내장 된 모든 것은 역할 및 인증과 같이 쓸모없는 것처럼 보입니다. 예를 들어, [Authorize] 속성 및 보안; 당신은 자신의 롤을해야합니다.
모든 API 호출에는 보안 정보가 첨부되어 있어야하며 토큰 시스템 등을 개발해야합니다.
프로그램이 수행 할 모든 단일 기능에 대해 완전한 API 호출을 작성해야합니다. 구현하려는 거의 모든 메소드를 API에서 실행해야합니다. 모든 사용자에 대한 가져 오기 / 업데이트 / 삭제와 서로 다른 작업 (예 : 사용자 이름 업데이트, 사용자를 그룹에 추가 등)에 대한 변형이 있으며 각각 고유 한 API 호출입니다.
API와 관련하여 인터페이스 및 추상 클래스와 같은 모든 종류의 도구가 손실됩니다. WCF 와 같은 기능은 인터페이스를 매우 강력하게 지원합니다.
사용자를 생성하거나 일부 작업을 수행하는 방법이 있습니다. 50 명의 사용자를 만들려면 50 번만 호출하면됩니다. 이 방법을 API로 사용하기로 결정하면 로컬 웹 서버가 명명 된 파이프에 연결할 수 있으며 아무런 문제가 없습니다. 데스크톱 클라이언트도 충돌 할 수 있지만 갑자기 대량 사용자 생성에는 인터넷을 통해 API를 50 번 망치게됩니다. 좋지 않아 따라서 대량 메서드를 만들어야하지만 실제로는 데스크톱 클라이언트 용으로 만드는 것입니다. 이 방법으로 a) 통합하는 것을 기반으로 API를 수정하고 직접 통합 할 수는 없으며 b) 추가 기능을 만들기 위해 더 많은 작업을 수행해야합니다.
야 그니 . 예를 들어 하나의 웹과 하나의 Windows 응용 프로그램과 같이 동일한 기능을하는 두 개의 응용 프로그램을 작성할 계획이 아니라면 엄청난 양의 추가 개발 작업입니다.
엔드 투 엔드를 단계별로 진행할 수 없으면 디버깅이 훨씬 어려워집니다.
예를 들어, 일부 코드는 현재 사용자를 얻거나, 사용자가 관리자 역할에 있는지 확인하고, 사용자가 속한 회사를 얻거나, 다른 구성원의 목록을 얻고, 모두를 보낼 수 있습니다. 이메일. 이를 위해서는 많은 API 호출이 필요하거나 원하는 특정 작업을 위해 맞춤형 메소드를 작성해야합니다.이 맞춤형 메소드의 유일한 이점은 속도이지만 단점은 융통성이 없을 것입니다.
아마도 더 많은 이유는 이것들이 내 머리 꼭대기에 있습니다.
두 개의 동일한 응용 프로그램이 실제로 필요하지 않으면 나에게 좋아 보입니다. 그러면 가치가 없습니다. 이처럼 빌드 된 ASP.NET 응용 프로그램을 본 적이 없으므로 두 개의 별도 응용 프로그램 (API 및 코드)을 작성하고 버전을 제어해야합니다 (사용자 페이지에 새로운 필드가 있으면 d API와 소비 코드를 동시에 업데이트하여 악영향을 방지하거나 강력한 추가 작업을 수행해야합니다.
편집 : 몇 가지 훌륭한 반응, 실제로 이것이 모두 의미하는 바를 시작하기 시작했습니다. 내 질문을 확장하기 위해이 API 구조를 따르도록 MVC 앱을 어떻게 구성합니까?
예를 들어, 사용자에 대한 정보를 표시하는 웹 사이트가 있습니다. MVC에서는 다음이 있습니다.
UserViewModel Controller를 표시하는 View-(CS) HTML 페이지-GetUser ()를 호출하고 GetUser 메소드가있는 View Manager 클래스 (API 정렬)에 전달하는 UserViewModel을 작성합니다.
컨트롤러는 GetUser ()를 수행하지만 데스크톱 앱도 필요합니다. 이것은 GetUser가 어떤 종류의 API를 통해 노출되어야 함을 의미합니다. TCP 연결 (WCF 또는 원격)을 원할 수 있습니다. 지속적인 연결이 약하기 때문에 RESTful 한 모바일 앱도 필요합니다.
그러면 GetUser () 메소드를 가진 WCF 웹 서비스와 각각의 API를 작성하고 코드는 그냥 수행 return new UserManager().GetUser()합니까? 그리고 같은 일을하는 mvc 4 웹 API 방법? MVC 컨트롤러 메소드에서 직접 GetUser를 계속 호출하면서?
또는 세 가지 (웹 API REST 서비스) 모두에 대해 작동하는 솔루션을 선택하고 그 위에 모든 것을 구축하여 세 가지 앱 모두 API 호출 (mvc 호출)을 로컬 컴퓨터로 만듭니다.
그리고 이것은 이론적으로 완벽한 시나리오입니까? 특히 RESTful 방식으로 작업을 수행 할 수있는 방식으로 개발해야하는 경우 이러한 방식으로 개발할 때 큰 오버 헤드가 발생할 수 있습니다. 나는 이것들 중 일부가 답장에 포함되어 있다고 생각합니다.
편집 2 : 더 많은 내용을 읽은 후에는 설명 할 수 있다고 생각하는 의견을 아래에 넣었습니다. 질문은 내가 생각하는 약간의 트릭 질문입니다. API로 백엔드를 작성하면 혼란스럽게 생각하면 모든 것이 (mvc 앱, 데스크톱 앱, 모바일 앱) 호출하는 단일 웹 서비스가 있어야한다고 생각합니다.
결론은 비즈니스 로직 계층이 올바르게 분리되었는지 확인하는 것입니다. 내 코드를 보면 이미이 작업을 수행합니다. 컨트롤러가 GetUser()관리자 를 호출 한 다음 뷰에서 렌더링 할 뷰 모델을 만듭니다. 실제로 비즈니스 로직 계층 은 API입니다. 그러나 데스크톱 앱에서 호출하려면 WCF 서비스와 같은 것을 작성하여 쉽게 호출해야합니다. GetUser()코드를 포함 하는 WCF 메소드 만 return MyBusinessLayer.GetUser()있으면 충분합니다. 따라서 API는 비즈니스 로직이며 WCF / 웹 API 등은 외부 응용 프로그램이 호출 할 수있는 코드입니다.
따라서 비즈니스 로직 계층을 필요한 것에 따라 다른 API로 랩핑해야하고 다른 앱에서 수행하려는 각 작업마다 API 메소드를 작성해야한다는 오버 헤드가 있습니다. 인증을 수행하는 방법을 정렬하지만 대부분 동일합니다. 비즈니스 로직을 별도의 프로젝트 (클래스 라이브러리)에 집어 넣으면 아무런 문제가 없을 것입니다!
이 해석이 정확하기를 바랍니다. 모든 토론 / 의견에 감사드립니다.