비즈니스 로직이 실제로 서버에 속합니까?

웹 애플리케이션의 일반적인 스택은 데이터베이스, 서버 측 코드가있는 서버 및 HTML / CSS / JavaScript가있는 브라우저가있는 사용자입니다.

광범위한 AJAX 이전에는 컨트롤러가 서버 측 코드 인 MVC가 중단되었습니다. 서버는 동적 웹 페이지 (예 : JSP 및 ASP와 같은 템플릿 HTML 솔루션)에 대한 응답 요청을 라우팅해야했습니다. 서버는 데이터베이스 호출을 조정하고 페이지 요청에 응답하는 데 사용할 동적 페이지를 결정합니다. 이 모든 결과는 비즈니스 로직이 페이지를 제공한다는 아이디어와 밀접한 관련이 없더라도 서버에 비즈니스 로직이 포함 된 결과입니다.

이제 JavaScript를 사용하여 자신을 채우고 표시하는 내용을 변경하는 서버 서버 정적 페이지 인 "Web 2.0"으로 이동합니다. JavaScript에있을 수 있습니다. JavaScript는 종종 데이터베이스 쿼리를 지정한다는 의미의 RESTful 서비스를 구현합니다.

따라서 서버는 실제 파일을 제공하고 AJAX 호출에 응답하는 역할을 담당합니다. AJAX 호출에 응답하는 것은 세션 관리 및 보안을 제공하는 것입니다. 실제로 사용자가 볼 수있는 것은 데이터베이스에 지정해야하는 데이터입니다.

그렇다면 서버는 가끔 이메일을 보내거나 웹 서비스를 시작하는 것과 같은 바보 같은 중개인의 역할로 위임되어야합니까? 비즈니스 로직이 모두 JavaScript (비밀이 아닌 경우)에 있거나 저장 프로 시저에있을 수 있습니까?

서버와 데이터베이스를 결합하거나 SAP와 같은 ERP 솔루션을 서버로 작동시키는 것이 합리적일까요?

비즈니스 로직은 거의 항상 보안상의 이유로 제어하는 ​​서버에서 실행해야합니다. "서버"가 "웹 서버"를 의미하는 경우 거의 모든 비즈니스 로직이 필요하지 않습니다. 그러나 데이터베이스 나 웹 서버 내부에 있거나 웹 서버에 의해 분리되어 호출되는지 여부에 관계없이 거의 항상 비즈니스 로직을 갖춘 응용 프로그램 서버가 필요합니다.

웹 서버가 웹 서비스 또는 JSON을 통해 응용 프로그램 서버의 API를 노출시키는 것 외에는 실제 응용 프로그램이 있습니다.

Web 2.0 및 AJAX 이전에도 비즈니스 로직을 ASP 페이지와 혼합하는 것이 가장 좋은 방법은 아닙니다. 독립적 인 비즈니스 로직을 갖고 프리젠 테이션 로직의 서버 부분을 ASP, JSP 등으로하는 것이 더 좋을 것으로 생각되었습니다. 따라서 웹 2.0과의 실질적인 변화는 프리젠 테이션 레이어가 완전히 자바 스크립트 일 수 있다는 것입니다. 개인적으로 선호합니다.

JavaScript는 종종 데이터베이스 쿼리를 지정한다는 의미의 RESTful 서비스를 구현합니다.

여기가 잘못되었습니다. REST는 CRUD 가 아닙니다 .

REST에 의해 노출 된 자원은 데이터베이스 레코드가 아닙니다. 비즈니스 로직에 따라 동작하는 완전히 관리되는 객체입니다. 서버가 POST 또는 PUT을 수신하면 유효성 검사 및 저장 만하면 안됩니다. 응용 프로그램에 적합한 모든 작업을 수행해야합니다.

간단한 예 : 트위터와 같은 앱은 지정된 컨테이너에서 POST 메시지로 트윗을받습니다. 그런 다음 서버는 컨텍스트 ( "누구입니까?", "어떤 채널입니까?") 및 컨텐츠 ( "해시 태그"?), 텍스트 인덱스 등을 분석하고이 모든 것을 각 큐에 저장합니다. 모든 추종자에게 직접 참조를 추가합니다.

그것은 단순히 컨테이너에 리소스를 추가하는 것 이상의 많은 작업이며, 비즈니스 로직에 의해 정의됩니다. 그리고 그것은 서버에 속합니다.

이 접근 방식에 대한 나의 관심은 당신의 디자인에 대한 오해 때문일 수 있습니다.

그러나 제품의 확장 성, 유지 관리 성 및 보안에 대해 생각하십시오.

제품이 대량으로 성장하면 데이터베이스에 병목 현상이 발생하므로 "성능"에 따라 비즈니스 로직을 저장 프로 시저에 넣는 것이 권장되지만, 데이터베이스 서버에 추가 CPU 부하가 발생하여 서버가 최대 용량에 도달 한 날을 앞 당깁니다. 웹 서버와 달리 ACID 데이터베이스는 병렬 하드웨어를 사용하여 쉽게 확장 할 수 없습니다. 귀하의 제품이 결코 성공하지 못할 경우 이는 문제가되지 않습니다.

다른 브라우저가 다른 javascriopt, 여러 버전의 브라우저 등을 필요로하는 웹 브라우저에서 실행되는 자바 스크립트에서 비즈니스 로직을 유지하려는 생각은 무엇입니까? 왜이 문제를 기존보다 더 복잡하게 만들 수 있습니까?

Javiar가 말했듯이 REST 접근법을 제품의 데이터베이스 API로 사용하는 것은 실제로 합리적이지 않습니다. REST 인터페이스의 장점은 다른 사람들이 REST 인터페이스를 사용하고 쿼리하는 다른 방법을 생각할 수 있다는 것입니다. 그러나 이것은 공공 사후 비즈니스 논리 자원이며 하위 레벨 테이블 레코드 자원이 아닙니다. HTTP API를 통해 이러한 낮은 수준의 데이터 쿼리를 사용할 수있게하려면 보안 악몽처럼 들립니다.

이것에 대해 많은 생각의 학교가 있으며, 확실히 어떤 방법도 보편적으로 "올바른 방법"이라고 부를 수는 없지만, 다른 모든 방법은 보편적으로 "잘못된 방법"이지만 서버 쪽에서 비즈니스 로직을 분리해야하는 여러 가지 이유가 있습니다 RESTful 서비스를 통해 해당 오브젝트 및 서비스에 액세스하십시오.

짧은 대답은 주로 위험 관리, 성능 모니터링 및 개선에 관한 것입니다.

상세히:

가장 중요한 이유는 보안입니다. 클라이언트는 가비지 이외의 다른 것을 서버에 제출할 것을 절대 신뢰할 수 없으며, 보안 측면을 서버 측에 유지함으로써 악의적 인 사용자가 시스템을 손상시킬 수있는 잠재적 위험을 격리 할 수 ​​있습니다. Javascript는 완전히 클라이언트 측이며 사소하게 변경 가능하므로 출력을 신뢰할 수 없습니다.

두 번째 이유는 우려의 분리입니다. 귀하의 Javascript 프로그래머는 보안 전문가가 아닐 수도 있으며, 보안 전문가는 Javascript에 능숙하지 않을 수도 있습니다. 비즈니스 로직을 프리젠 테이션 로직에서 분리하면 자바 스크립트가 권한 수준 이상의 리소스에 액세스 할 수없고 오류가 발생하므로 처리가 스크립트 프로그래머의 이전에 있기 때문에 이러한 문제를 피할 수 있습니다. 마찬가지로 보안 담당자는 보안 유지 방법을 확인하기 위해 Javascript를 디버깅하지 않습니다.

세 번째 이유는 성능입니다. 비즈니스 로직은 잠재적으로 서버 및 데이터베이스 리소스를 요구할 수 있습니다. 해당 논리를 UI 요소와 분리하여 유지하면 응용 프로그램의 해당 부분 만 확장하여 병목 현상을 훨씬 쉽게 해결할 수 있습니다. 또한 비즈니스 프로세스가 서버에서 실행되는 경우 시스템 또는 데이터베이스 백엔드를로드하는 비즈니스 프로세스를 분리하는 것이 훨씬 쉽습니다.

여기서는 여러 비즈니스 프로세스에서 동일한 데이터를 사용하기 때문에 서버 측에서 캐싱을 구현하여 클라이언트 측 코드에 액세스 할 수없는 / 안전하지 않은 전체 시스템로드를 줄일 수 있습니다.

마지막으로 ACID 표준을 유지하려면 Business Logic이 실제로 서버에 있어야한다고 제안합니다. 서버에 대한 데이터베이스 연결만으로 웹 브라우저에서 실행 된 결제 제품을 유지 관리하는 것을 기억합니다. 브라우저가 닫히거나 충돌하여 일일 청구 (좋은 날에는 1 시간 이상 소요될 수 있음)가 중단 된 경우 데이터베이스로 인한 혼란을 해결하는 데 몇 시간이 걸릴 수 있습니다. 일관성이없는 상태 여기에는 신용 카드도 포함되므로 결제 기록도 프로세서와 비교하여 확인해야합니다!

응용 프로그램 또는 데이터베이스 수준에서 트랜잭션을 유지 관리하는 모든 언어에 대한 프레임 워크가 있기 때문에 서버 측 비즈니스 로직은 ACID 업데이트를 보장하기에 대부분 사소합니다. 웹 클라이언트에서 여러 업데이트를 통해이 작업을 수행하는 경우 어느 시점에서 일관성이없는 상태가되어 응용 프로그램에 영향을 줄 수 있습니다.

RESTful 서비스를 단순히 데이터베이스에 액세스하는 방법으로 생각하고 싶더라도 재난에 대한 좋은 레시피이므로이 함정에 빠지지 않아야합니다. RESTful 서비스를 통해 공개하는 오브젝트 모델은 데이터베이스와 관련이있을 수 있지만 CRUD 엔진으로 사용하는 대신 비즈니스 로직을 실제로 캡슐화해야합니다.