모든 UI 로직을 클라이언트 측으로 옮기시겠습니까?

9

우리 팀은 원래 Javascript에 대한 최소한의 전문 지식을 갖춘 대부분의 서버 측 개발자로 구성되었습니다. ASP.NET에서는 코드 숨김 또는 더 최근에는 MVC의 컨트롤러를 통해 많은 UI 로직을 작성했습니다.

얼마 전 2 명의 고급 클라이언트 측 개발자가 우리 팀에 합류했습니다. HTMl / CSS / Javascript에서 이전에 서버 측 코드 및 서버 측 웹 컨트롤로 할 수있는 모든 작업을 수행 할 수 있습니다.

컨트롤 표시 / 숨기기
유효성 검사
AJAX 리프레쉬 제어

: 나는 그렇게 생각하기 시작 그래서 어쩌면 좀 아마존 이행의 API처럼, 우리의 비즈니스 로직 주위에 높은 수준의 API를 생성하는 것이 더 효율적이 될 것 http://docs.amazonwebservices.com/fws/latest/APIReference/ , 해당 클라이언트 때문에 사이드 개발자는 UI를 완전히 인수하고 서버 사이드 개발자는 비즈니스 로직에만 집중합니다.

따라서 주문 시스템의 경우 다음과 같은 고급 API가 있습니다.

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

API에 대한 JSON / REST 액세스가 있으므로 클라이언트 측 UI에서 쉽게 사용할 수 있습니다. 내부 API 개발 및 타사에서이 API를 사용하여 자체 응용 프로그램을 만들 수 있습니다.

Javascript의 발전과 우수한 클라이언트 측 개발자의 가용성으로 인해 코드 숨김 / 컨트롤러를 제거하고 클라이언트 측 개발자가 사용할 수있는 고급 API (ala Amazon)를 개발하는 데 집중해야 할 때입니까?

— Mag20
소스

6

서버 측을 오프로드하고 응용 프로그램의 응답 성을 높이기 위해 클라이언트 측에서 검증하는 것은 좋지만 항상 서버 측 검증을 수행합니다. JavaScript를 끌 수 있으며 REST API를 직접 사용할 때 JavaScript가 필요하지 않습니다.

— Htbaa
소스

예, 유효성 검사도 도메인 / API의 일부입니다. 클라이언트 측은 API에서 검증해야 할 사항을 가져 오거나 각 방법에 필요한 사항 등을 문서화합니다. 클라이언트 측에서 제출할 때 여전히 유효성 검사 오류가있는 경우 예외가 발생합니다.

— Mag20

4

한 가지 알아야 할 것은 복잡한 UI에는 비즈니스 계층에 실제로 존재하지 않는 계층 구조, 마스터 / 세부 관계 및 기타 UI 개념과 같은 항목을 지원하기 위해 추가 "UI 지원"계층이 필요할 수 있다는 것입니다. 비즈니스 계층으로 여러 번 왕복하지 않고 이러한 기능 중 일부를 구현할 수없는 경우가 많으므로 성능이 저하됩니다. 적어도 UI에 데이터베이스에 대한 직접 액세스 권한을 부여하기 위해 "UI 지원"계층을 선호합니다.

— TMN
소스