클라이언트와 서버 간에 비즈니스 로직이 반복되지 않도록 하려면 어떻게 해야 합니까?

클라이언트와 서버 간에 비즈니스 로직이 반복되지 않도록 하려면 어떻게 해야 합니까?

웹 앱에 대한 요구가 커지면서 API 기반의 웹 애플리케이션을 점점 더 많이 쓰게 되었습니다.나는 Angular와 같은 틀을 사용한다.JS는 이러한 API와 통신하는 리치 웹 클라이언트를 구축합니다.현재 서버측/API로 PHP(Lumen 또는 Laravel)를 사용하고 있습니다.

문제는 클라이언트 측과 서버 측 사이에서 비즈니스 논리를 자주 반복한다는 것입니다.

제가 비즈니스 로직을 말하는 것은 주문 양식에 대한 다음과 같은 규칙을 의미합니다.

• Y를 사면 X를 살 수 있어요.
• Z가 있으면 Y를 살 수 없습니다.
• 이거 10개 사면 10% 할인해 드립니다.
• 높이 x 폭 x 깊이 x 비용 = 최종 비용.
• 폭이 5보다 클 경우 높이는 10에서 20 사이여야 합니다.
• 기타 등

이 앱의 응답성과 고속화를 위해 클라이언트 측에서 (다른 비즈니스 로직과 함께) 계산을 위한 로직이 이루어지고 있습니다.클라이언트를 신뢰하면 안 되기 때문에 서버 측에서 그 번호를 다시 검증합니다.이 논리는 매우 복잡해질 수 있고, 양쪽에서 이 복잡한 논리를 쓰는 것은 위험하게 느껴집니다.

다음 세 가지 솔루션을 염두에 두고 있습니다.

1. 비즈니스 로직이 필요한 모든 것을 API에 Ajax 호출합니다.모든 비즈니스 로직이 한 곳에서 작동하며 한 번 테스트할 수 있습니다.클라이언트는 갱신된 값과 결과를 얻기 위해 주문 양식에 대한 모든 변경을 기다려야 하기 때문에 이 작업은 느릴 수 있습니다.매우 빠른 API가 있으면 도움이 될 것입니다.주된 단점은 사용자가 접속 상태가 좋지 않은 경우(모바일 디바이스)에는 이 기능이 제대로 작동하지 않을 수 있다는 것입니다.

2. 클라이언트측과 서버측에서 비즈니스 로직을 작성합니다.클라이언트는 양식에 변경을 가할 때 피드백을 즉시 받을 수 있으며, 모든 데이터는 서버에 제출되면 검증됩니다.단점은 모든 비즈니스 로직을 복제하여 양쪽을 테스트해야 한다는 것입니다.이것은 확실히 더 많은 작업이고 미래의 작업을 취약하게 만들 것이다.

3. 고객을 믿어라!?클라이언트 측에 모든 비즈니스 로직을 작성하고, 데이터를 조작하지 않았다고 가정합니다.현재 시나리오에서는 항상 사람이 검토하는 견적 작성 작업을 하고 있기 때문에 이 정도면 괜찮을지도 모릅니다.

솔직히 어떤 해결책도 마음에 들지 않아 커뮤니티에 조언을 구하고 있습니다.이 문제에 대한 당신의 의견이나 접근법을 듣고 싶습니다!

한 가지 더 할 수 있어요.

JavaScript만으로 검증 및 비즈니스 로직 코드를 생성하십시오.하지만 가능한 한 느슨하게 연결하세요.가능하면 JSON만 입력으로 사용하고 JSON을 출력으로 지정합니다.

그런 다음 별도의 노드를 설정합니다.클라이언트 측에서 AJAX 호출 없이 사용할 수 있도록 기존 PHP 서버와 함께 JS 서버를 사용하여 로직을 클라이언트에 제공합니다.

그런 다음 PHP 서버에서 이러한 모든 비즈니스 로직 규칙을 검증하고 실행해야 할 경우 cURL을 사용하여 NodeJS 비즈니스 로직을 호출하고 데이터를 검증합니다.이는 PHP 서버에서 노드로의 HTTP 호출을 의미합니다.JS 서버노드JS 서버에는 데이터를 가져와 동일한 코드로 검증하고 결과를 반환하는 추가 코드가 있습니다.

이렇게 하면

1. 개발 속도 향상 - 로직을 한 곳에서 테스트합니다.
2. 클라이언트 코드 실행 속도 향상 - 동일한 검증 JavaScript 코드가 노드에서 처리되므로 AJAX 필요 없음고객에게 JS를 전달합니다.
3. 모든 비즈니스 로직은 노드에 존재합니다.JS 서버 - 비즈니스 로직이 변경될 때 이 부분만 누르면 됩니다. 따라서 가까운 시일 내에 다른 인터페이스를 만들어야 할 경우 이 서버를 사용하여 데이터를 검증할 수 있습니다.비즈니스 규칙 서버와 동일하게 작동합니다.

필요한 것은 노드 셋업뿐입니다.PHP 서버와 함께 JS 서버.그러나 노드에서 실행하기 위해 모든 코드를 변경할 필요는 없습니다.JS 서버

백엔드는 라라벨, 프론트엔드는 Angular 2를 사용하여 어플리케이션을 만들었을 때도 같은 문제가 있었습니다.또, 지금까지의 비즈니스 로직의 중복을 회피할 수 있는 솔루션은 없는 것 같습니다.그 이유는 다음과 같습니다.

현재 PHP와 JavaScript는 서로 변환할 수 없습니다.비즈니스 로직 작성에 같은 언어를 사용하여 백엔드와 프런트엔드에 모두 삽입할 수 있으면 좋겠습니다.여기서부터 다른 포인트로 넘어갑니다.

목표를 달성하려면 비즈니스 로직을 한 언어로만 작성해야 하며, 현재까지는 JavaScript가 가장 좋은 솔루션입니다.아시다시피 TypeScript/EMCA Script는 OOP 방식으로 코드를 작성하는 데 도움이 됩니다.Meteor Framework NodeJS 인프라스트럭처는 백엔드 및 프론트엔드 양쪽에서 실행할 수 있도록 JavaScript로 코드를 작성하는 데 도움이 됩니다.

따라서 제 관점에서는 비즈니스 로직용 패키지를 작성하기 위해 TypeScript/EMCA를 사용할 수 있습니다.예를 들어 JavaScript로 작성된 검증용 클래스는 양쪽에서 구현이 가능하기 때문에 1회만 쓸 수 있지만 프런트엔드와 백엔드에서도 2회 호출됩니다.

그것이 제 의견이에요.이 매우 흥미로운 주제에 대한 다른 해결책을 찾길 바랍니다.

가능한 해결책 중 하나는 XML 또는 JSON Schema와 같은 선언적 추상 언어로 검증 규칙을 선언하는 것입니다.

클라이언트 측에서는 예를 들어 AngularJS라고 합니다.이러한 규칙을 기성 형식 렌더러로 변환할 수 있습니다.클라이언트 측에서는 선언된 규칙을 검증하는 폼이 생성됩니다.

그런 다음 서버 측 API에서 정의된 규칙에 따라 검증할 재사용 가능한 검증 엔진을 생성해야 합니다.

결과적으로 JSON 스키마 또는 규칙을 선언적으로 정의하는 경우 폼 및 검증 규칙이 정의됩니다.

저도 제 프로젝트를 할 때 이 위치에 있었습니다.클라이언트 디바이스의 파워를 사용하여 무거운 작업을 수행하고 서버 측에서 결과를 검증하는 것은 항상 매력적입니다.그 결과 비즈니스 로직이 프런트엔드와 백엔드로 두 번 나타납니다.

옵션 1이 가장 좋은 옵션이라고 생각합니다.가장 타당하고 논리적으로도 보입니다.향후 웹 앱을 네이티브 모바일 앱으로 확장하고 싶다면 API를 호출하여 모든 비즈니스 로직을 재사용할 수 있습니다.나한테는 엄청난 승리야

API 요구를 너무 많이 해서 모바일 퍼포먼스에 영향을 줄 수 있다는 우려가 있다면 요청을 몇 개 그룹화하여 마지막에 한 번 체크해 보는 것은 어떨까요?따라서 양식에서 각 필드를 확인하는 대신 사용자가 전체 양식을 제출할 때 확인합니다.또한 최소한의 데이터 요청 및 응답만 해주면 대부분의 인터넷 연결로도 충분하므로 걱정하지 않겠습니다.

더 큰 문제는 웹 앱이 여러 섹션으로 나뉘어 각 섹션이 관련 API를 호출한다는 것입니다.사용자가 이러한 상태 사이를 이동할 수 있기 때문에 앱의 상태는 훨씬 더 이해하기 복잡합니다.사용자 이동에 대해 매우 신중하게 생각하고 프로세스가 불안정하지 않은지 확인해야 합니다.

다음은 제가 대처해야 했던 공통적인 문제 중 몇 가지입니다.

• API가 반환되면 프런트엔드에 오류가 표시됩니까?
• 사용자가 실수로 양식을 제출했다면 오류가 표시됩니다.그러나 사용자가 오류를 수정하고 다시 제출하면 오류가 숨겨지고 성공 메시지가 나타납니다.
• API가 버그가 있거나 인터넷 연결이 불안정하여 아무것도 반환되지 않으면 어떻게 합니까?앞부분이 걸리나요?
• 오류 메시지가 여러 개 있는 경우 프론트 엔드에 모두 표시될 수 있습니까?

비즈니스 로직이 백엔드에만 있는 경우에도 프런트엔드에 유닛 테스트를 많이 실시하여 안정성을 확보할 것을 권장합니다.

우선, 클라이언트는 절대 신뢰하지 말아 주세요.

그렇다고는 해도, 나는 항상 이것에 대처하고 있어, 애석하게도 쉬운 해결책을 찾지 못하고 있다.양쪽에서 검증을 수행해야 하지만 양쪽에서 전체 검증을 수행할 필요는 없습니다.

내가 하는 일은 균형을 맞추는 것이다.클라이언트측에서는, 대부분의 심플한(단, 중요한) 검증, 통상의 내용, 숫자, 날짜, 데이터, 범위내의 데이터등을 실시합니다.따라서, 송신할 때에 비해, 대부분의 정보는 서버에 송신되어 완전하게 검증됩니다.그러나 클라이언트측에서는, 최소한, 정보의 형식이 적절한 것을 확인하고 있습니다.그리고 그 중 일부(또는 대부분)는 이미 검증이 끝난 상태이지만, 실제 비즈니스 로직은 서버 측에서 이루어지지만, 대부분의 데이터가 이미 정확하기 때문에 서버 측 검증이 요청을 승인할 가능성이 높기 때문에 많은 재제출을 피할 수 있습니다.

어떻게 하면 바꿀 필요가 있을 때 양쪽에서 바꿀 필요가 없게 할 수 있을까요?주요 변경이 필요한 경우 이를 피할 수 없는 경우도 있지만 비즈니스 로직 매개 변수를 공유할 수 있습니다. 제안하신 대로 이 작업은 Ajax를 통해 수행할 수 있습니다.모든 비즈니스 로직 파라미터가 있는 php 파일을 만듭니다.ajax 요구를 사용하여 클라이언트 측에 로드합니다.이 파일을 최적화할 필요가 있는 것은 1회뿐입니다(스크립트가 로드되었을 때).파라미터 값만 취득하면 다른 모든 것은 클라이언트 측에 이미 존재합니다.따라서 비즈니스 로직의 일부 파라미터 값이 변경되면 파라미터 파일에서만 변경할 수 있습니다.(스크립트가 로드된 후 파라미터가 변경되면 서버 측에서 검증에 실패합니다.이때 강제로 스크립트를 다시 추가할지 여부를 결정해야 합니다.파라미터가 다시 로드되는지 여부를 결정해야 합니다.)

감이 잡히실 겁니다이게 제가 하는 일이고, 저한테는 꽤 잘 작동해서 녹음하는 시간을 많이 절약할 수 있어요.

도움이 되시길 바랍니다.

저는 앞으로 옵션 1이 최선이라고 생각합니다.API 최초 개발은 모든 비즈니스 로직을 테스트하고 올바르게 작동하며 인터페이스에 액세스할 수 있도록 합니다.절대 사용자를 믿어서는 안 됩니다!

필요한 인터페이스마다 동일한 로직을 몇 번이고 코딩하는 것에 비해 API의 최초 개발은 무제한입니다.

다음은 로직 클라이언트 측과 서버 측 중 어느 쪽을 배치할지에 대한 유사한 스레드입니다.결국, 각각의 상황은 독특하고 다른 계획이 필요하지만, 이 분야에는 좋은 가이드 팁이 몇 가지 있습니다.

클라이언트 측과서버측

오늘날 솔루션은 분명 @ParthaSarathiGhosh의 솔루션이지만 가까운 장래에 또 다른 솔루션이 될 것입니다.

Web Assembly는 응용 프로그램과 함께 배포하여 브라우저에서 실행할 수 있는 하위 수준의 어셈블리 언어입니다.어셈블리의 컴파일된 코드를 호출하여 JavaScript에서 로직을 요구할 수 있습니다.이는 클라이언트 측에서 실행되는 무거운 스크립트에 권장되지만 동시에 백엔드 코드를 전면에서 재사용할 수 있습니다.이렇게 하면 백엔드의 논리를 작성하여 앞에서 재사용할 수 있습니다.

현재 이 테크놀로지는 대부분의 최신 브라우저에서 이미 지원되고 있지만 c/c++에서만 사용할 수 있습니다.그래서 이런 스킬이 있으면 이미 쓸 수 있어요.

(c# - ex : blazor - 및 기타 언어에 대한 연구가 이미 있기 때문에) 다른 언어로도 확대할 예정입니다.그러나 성숙도는 생산에 충분히 안정되어 있지 않은 것 같습니다(블레이저 개발팀도 아직 생산에 권장하지 않습니다).

내 생각일 뿐이지만 => 노드의 논리JS는 javascript 코드를 재사용하는 솔루션이지만, 유지보수가 가능한 큰 로직 코드에 관해서는 여전히 강력한 타입의 언어가 필요하다고 느끼고 있습니다.(네, 저는 TypeScript를 알고 있고, 정말 좋지만, 뭔가 놓치고 있는 것이 있습니다.Web Assembly는 아직 조금 젊지만 DRY 원칙을 존중하기 위해 큰 개선을 가져올 것입니다.

매우 흥미로운 문제 - 또 다른 경고는 오프라인 모드를 지원하고자 한다는 것입니다. 즉, 앱도 오프라인에서 실행되어야 합니다.

또 하나의 복잡성은 서버 쪽이 java나 같은 하나의 테크놀로지에 모두 포함되어 있는 경우입니다.넷 등 클라이언트 측에서는 네이티브 툴과 Xamarin 중 하나를 선택하지만 유감스럽게도 서버와 동일하지는 않습니다.

그래서 Partha의 접근방식은 가장 유망해 보이지만, 언급했듯이 그것은 완전히 오프라인 모드에서는 작동하지 않을 것입니다.따라서 약간 변경된 접근법은 검증 규칙을 데이터로 간주하는 것입니다.그러나 단순한 데이터가 아니라 오히려 "전체 코드는 데이터"라고 말한다.Groovy, JavaScript, CScript 등 원하는 인터프리터 코드 언어를 선택할 수 있습니다.단, 모든 비즈니스 로직은 그 코드 안에 있습니다.

이것을 실현할 수 있는 경우는, 오프라인 모드로 데이터를 동기 하고 있을 때에, 매우 특수한 타입의 데이터(즉, 코드)도 동기화합니다(따라서, 「신뢰할 수 있는」클라이언트의 리스크는 없습니다).

그리고 오프라인 API와 온라인 API는 100% 동일한 코드이지만 코드는 우리의 통역 언어로 되어 있습니다.이 접근방식을 통해 이 문제를 해결할 수 있을 뿐만 아니라 비즈니스 로직 유지보수를 훨씬 단순화할 수 있을 것으로 생각합니다.규칙을 지원하기 위해 매우 복잡한 데이터 모델을 종종 만들었습니다. 실제로 2019년에는 if/eles를 사용하여 규칙을 쉽게 만들 수 있으며 훨씬 단순해질 것입니다.매우 심플한 스크립팅 툴로 최종 사용자를 교육하고 코드를 줄여서 더 나은 작업을 수행할 수 있습니다.

https://medium.com/@thesaadahmad/business-logic-conundrum-mobile-mobile-http-a06ecc134aee라는 아이디어로 블로그 투고를 작성했습니다.

언급URL : https://stackoverflow.com/questions/37502754/how-to-avoid-repeating-business-logic-between-client-and-server