소프트웨어 아키텍처는 응용 프로그램 내에서 생성된 구조, 즉 전체 프로그램의 모듈 및 구성 요소와 이들이 상호 작용하는 방식을 나타냅니다. 프로그래머들은 아주 오랫동안 좋은 아키텍처에 대해 작업해왔기 때문에 우리가 많은 아키텍처 패턴에 대해 들어본 것은 놀라운 일이 아닙니다. 그것들을 이해해야 합니다. 웹 애플리케이션을 작성할 때 웹 애플리케이션에는 일반 애플리케이션보다 더 많은 구성 요소와 모듈이 있기 때문에 좋은 아키텍처를 제시하는 것이 중요합니다. 아키텍처 패턴일부 소프트웨어 설계 문제를 해결하는 현명한 방법입니다. 팩토리 메소드, 추상 팩토리, 빌더, 프로토타입, 싱글톤 등과 같은 디자인 패턴을 접해보셨을 것입니다. 우리는 코드를 작성하고, 클래스를 생성하고, 클래스가 상호 작용하는 방식을 계획할 때 이를 사용합니다. 아키텍처 패턴은 서버, 데이터 및 기타 구성 요소와 사용자의 상호 작용을 계획할 때 더 높은 수준의 추상화에서 사용됩니다. 몇 가지 패턴과 사용 방법을 간단히 살펴보겠습니다.
클라이언트-서버 아키텍처
이름은 이 패턴에 대한 모든 것이 단순하고 명확하다는 인상을 줍니다. 그러나 Spring을 공부하기 시작할 때 우리가 말하는 내용을 이해할 수 있도록 몇 가지 사항을 명확히 합시다. 채팅 앱을 작성했고 친구와 함께 사용하기 시작했다고 가정해 보겠습니다. 알려진 IP 주소를 사용하여 인터넷을 통해 서로에게 직접 메시지를 보내는 매우 간단한 접근 방식을 채택할 수 있습니다.
처음에는 다른 친구가 채팅 참여를 요청할 때까지 모든 것이 잘 작동하는 것처럼 보입니다. 따라서 서로 친구를 채팅에 추가하기로 결정하면 아키텍처 문제에 직면하게 됩니다. 각 채팅 참가자에 대해 사용자 수에 대한 현재 정보와 새 사용자의 IP 주소를 제공해야 합니다. 그리고 메시지를 보내면 모든 참여자에게 전달되어야 합니다. 이것은 발생할 가장 명백한 문제입니다. 또 다른 많은 문제는 코드 자체에 숨겨져 있습니다. 이를 방지하려면 서버를 사용해야 합니다., 주소를 포함하여 사용자에 대한 모든 정보를 저장합니다. 메시지는 서버로만 보내면 됩니다. 차례로 각 수신자에게 메시지를 보냅니다. 채팅 앱에 서버 부분을 추가하기로 결정하면 클라이언트-서버 아키텍처를 구축하기 시작합니다.
클라이언트-서버 아키텍처의 구성 요소
그것이 무엇인지 봅시다. 클라이언트 -서버 아키텍처는 웹 애플리케이션을 만드는 데 사용되는 디자인 패턴입니다. 이 아키텍처는 세 가지 구성 요소로 구성됩니다.
-
클라이언트 — 이름에서 이 구성 요소가 일부 서비스(웹 응용 프로그램)를 사용하고 서버에 연결하여 일부 정보를 요청한다는 것을 알 수 있습니다.
-
서버 — 웹 애플리케이션 또는 웹 애플리케이션의 서버 부분이 있는 곳입니다. 필요한 사용자 정보를 저장하거나 요청할 수 있습니다. 또한 클라이언트가 요청을 보낼 때 요청된 정보를 반환하는 것은 서버입니다.
-
네트워크 — 이 부분은 간단합니다. 클라이언트와 서버 간의 정보 교환을 용이하게 합니다.
-
클라이언트 모듈 — 로그인 및 메시지 송수신을 위한 그래픽 인터페이스 포함
-
서버 모듈 — 서버에서 호스팅되고 사용자로부터 메시지를 수신하고 처리한 다음 수신자에게 보내는 웹 응용 프로그램
인터넷에서 유용한(또는 그다지 유용하지 않은) 정보를 보고 싶을 때 우리는 브라우저를 열고 검색창에 검색어를 입력한 다음 검색 엔진에서 그에 대한 응답으로 정보를 얻습니다. 이 체인에서 브라우저는 클라이언트입니다. 그것은 우리가 찾고 있는 것에 대한 정보와 함께 요청을 서버로 보냅니다. 서버는 요청을 처리하고 가장 관련성이 높은 결과를 찾아 브라우저(클라이언트)가 이해할 수 있는 형식으로 패키징하고 다시 보냅니다. 검색 엔진과 같은 복잡한 서비스에는 많은 서버가 있을 수 있습니다. 예를 들어 권한 부여 서버, 정보를 찾는 서버, 응답을 생성하는 서버 등이 있습니다. 그러나 클라이언트는 이 중 어느 것도 인식하지 못하고 이에 대해 관심이 없습니다. 클라이언트에게 서버는 통합된 개체입니다. 클라이언트는 진입점에 대해서만 알고 있습니다. 즉, 요청을 보내야 하는 서버의 주소. 우리가 조사한 응용 프로그램을 기억하십시오.이 시리즈의 이전 부분 . 실시간으로 모든 국가의 평균 기온을 모니터링하기 위해서였습니다. 아키텍처는 다음과 같습니다. 
애플리케이션은 서버에 있습니다. 5초마다 지역 기상청이 운영하는 서버에 요청을 보내고 서버로부터 특정 국가의 온도 정보를 받아 이 정보를 저장한다고 가정해 보겠습니다. 클라이언트가 "세계의 현재 기온 보기"를 요청하면 가장 최근에 저장된 정보를 국가별로 정렬하여 반환합니다. 따라서 우리의 애플리케이션은 서버(사용자 요청을 처리할 때)와 클라이언트(다른 서버로부터 정보를 받을 때)의 역할을 모두 수행합니다.
| 여기에 중요한 점이 있습니다. 서버의 개념은 특정 컴퓨터에 관한 것이 아니라 네트워크 엔티티 간의 관계에 관한 것입니다 . |
3계층 아키텍처
이것은 세 번째 모듈인 데이터 스토리지를 도입하는 아키텍처 패턴입니다 . 이 패턴에서 세 가지 수준은 일반적으로 계층 또는 계층이라고 합니다.
-
클라이언트 계층은 프레젠테이션 계층이라고도 하는 사용자 인터페이스입니다. HTML 페이지를 수신하는 웹 브라우저이거나 JavaFX를 사용하여 작성된 그래픽 사용자 인터페이스일 수 있습니다. 가장 중요한 것은 이 계층을 통해 사용자가 서버에 요청을 보내고 응답을 처리할 수 있다는 것입니다.
-
논리 계층은 요청/응답을 처리하는 서버입니다. 종종 서버 계층이라고도 합니다. 여기에서 수학적 계산, 데이터 작업, 다른 서비스 또는 데이터 저장소에 대한 호출 등 모든 논리적 작업이 수행됩니다.
-
데이터 계층은 데이터베이스 서버입니다. 우리 서버는 데이터베이스 서버와 상호 작용합니다. 이 계층은 응용 프로그램이 작동하는 데 필요한 모든 정보를 저장합니다.
3계층 아키텍처의 장점
이와 같은 아키텍처는 다음과 같은 많은 이점을 제공합니다.
-
SQL 인젝션으로부터 보호하는 기능(이는 서버에 대한 공격이며 실행 시 공격자가 데이터베이스에 영향을 줄 수 있는 SQL 코드 전송이 포함됨)
-
사용자 액세스를 제어하려는 데이터의 분리.
-
데이터를 클라이언트에 보내기 전에 수정하는 기능.
-
확장성(동일한 데이터베이스를 사용할 여러 서버로 응용 프로그램을 확장하는 기능.
-
사용자 연결 품질에 대한 덜 엄격한 요구 사항. 서버에서 응답을 생성할 때 데이터베이스에서 다양한 정보를 많이 가져와서 형식을 지정하고 사용자에게 필요한 정보만 남기는 경우가 많습니다. 이렇게 하면 클라이언트에 대한 응답으로 보내는 정보의 양이 줄어듭니다.