자바 3티어 아키텍처의 원리와 기능 요약(그림)

이 글에서는 주로 Java 3-tier 아키텍처의 개념과 기능을 소개합니다. 도움이 필요한 친구들은

3-tier 아키텍처

3계층 애플리케이션(3-tier 애플리케이션) 일반적인 의미에서 3계층 아키텍처는 전체 비즈니스 애플리케이션을 다음과 같이 나눕니다.

프레젠테이션 계층(UI), 비즈니스 로직 계층(BLL), 데이터 액세스 계층(DAL). 레벨을 구분하는 목적은 "고 응집력, 저 결합도"라는 아이디어입니다.

개념소개

1. 프리젠테이션 레이어(UI): 일반 용어로 표시되는 인터페이스입니다. 사용자, 즉 사용자가 시스템을 사용할 때 보고 얻는 것입니다.

2. 비즈니스 로직 계층(BLL): 특정 문제에 대한 작업은 데이터 계층 및 데이터의 비즈니스 로직 처리에 대한 작업이라고도 할 수 있습니다. ​

3. 데이터 액세스 계층(DAL): 이 계층에서 수행되는 트랜잭션은 데이터 추가, 삭제, 수정, 검색 등을 위해 데이터베이스를 직접 운영합니다.

개요

소프트웨어 아키텍처 설계에서 계층 구조는 가장 일반적이고 중요한 구조입니다. Microsoft에서 권장하는 계층 구조는 일반적으로 아래에서 위로 데이터 액세스 계층, 비즈니스 논리 계층(도메인 계층이라고도 함), 프레젠테이션 계층의 세 가지 계층으로 나뉩니다.

3계층 구조 원칙:

3계층에서는 시스템의 주요 기능과 비즈니스 로직이 비즈니스 로직 계층에서 처리됩니다.

소위 3계층 아키텍처는 클라이언트와 데이터베이스 사이에

구성 요소 계층이라고도 하는 "중간 계층"을 추가합니다. 여기서 언급된 3계층 시스템은 단순히 3개의 물리적 계층을 의미하는 것이 아니며, 이는 3계층 아키텍처인 B/S 애플리케이션뿐만이 아닙니다. 3계층 시스템은 세 개의 계층이 하나의 시스템에 배치되어 있는 경우에도 논리적 시스템을 의미합니다.

3계층 시스템 애플리케이션은 비즈니스 규칙, 데이터 액세스, 합법성 확인 및 기타 작업을 중간 계층에 배치하여 처리합니다. 일반적으로 클라이언트는 데이터베이스와 직접 상호 작용하지 않고 COM/DCOM 통신을 통해 중간 계층과 연결을 설정한 후 중간 계층을 통해 데이터베이스와 상호 작용합니다.

각 계층의 기능

1:

데이터 데이터 액세스 계층: 주로 원시 데이터(데이터베이스 또는 텍스트 파일 등)용 ) , 원본 데이터가 아닌, 즉 데이터베이스가 아닌 데이터의 운영으로, 구체적으로 비즈니스 로직 레이어 또는 프리젠테이션 레이어에 대한 데이터 서비스를 제공합니다.

2:

비즈니스 로직 레이어. : 주로 특정 문제의 작동을 위한 것입니다. 데이터 계층의 작동 및 데이터 비즈니스 로직의 처리로 이해될 수도 있습니다. 데이터 계층이 구성 요소라면 논리 계층은 구성입니다. 이 빌딩 블록 중.

3:

프레젠테이션 레이어: 는 주로 WEB 모드를 나타내며, WINFORWEB 모드로도 표현할 수 있습니다. aspx, 로직 레이어가 상당히 강력하고 완전하다면 프리젠테이션 레이어가 어떻게 정의되고 변경되더라도 로직 레이어는 완벽하게 서비스를 제공할 수 있습니다.

구별하는 구체적인 방법

1: 데이터 데이터 액세스 계층: 주로 데이터 계층에 논리적 처리가 포함되어 있는지 여부에 따라 다릅니다.

함수는 주로 데이터 파일에 대한 다양한 작업을 완료합니다. 다른 작업에 대해서는 걱정하지 마세요.

2: 비즈니스 로직 계층: 주로 데이터 계층의 운영을 담당합니다. 즉, 일부 데이터 영역 작업을 결합합니다.

3: 프리젠테이션 계층: 주로 사용자 요청을 수락하고 데이터를 반환하여 클라이언트에 애플리케이션 액세스를 제공합니다.

프리젠테이션 레이어

는 사용자에게 가장 가까운 가장 바깥쪽 레이어(상위 레이어)에 위치합니다. 데이터를 표시하고 사용자가 입력한 데이터를 수신하는 데 사용되며 사용자에게 대화형 인터페이스를 제공합니다.

비즈니스 로직 레이어

비즈니스 로직 레이어는 의심할 여지없이 시스템 아키텍처의 핵심 가치를 반영하는 부분입니다. 주로 비즈니스 규칙의 공식화, 비즈니스 프로세스의 구현 및 비즈니스 요구와 관련된 기타 시스템 설계에 중점을 두고 있습니다. 시스템이 다루는 비즈니스 로직 계층은 도메인 계층이라고도 합니다.

예를 들어 마틴 파울러(Martin Fowler)는 "엔터프라이즈 애플리케이션 아키텍처 패턴"이라는 책에서 전체 아키텍처를 프리젠테이션 계층, 도메인 계층, 데이터 소스 계층의 세 가지 주요 계층으로 나눕니다. 도메인 중심

디자인의 선구자로서 Eric Evans는 비즈니스 로직 레이어를 보다 세부적으로 구분하여 이를 애플리케이션 레이어와 도메인 레이어로 세분화하고 레이어링을 통해 도메인 로직과 도메인 로직 솔루션을 더욱 분리했습니다.

비즈니스 로직 계층은 시스템 아키텍처에서 중요한 역할을 하며 데이터 액세스 계층과 프레젠테이션 계층 사이에 위치하며 데이터 교환에서 연결 역할을 합니다. 레이어는 약하게 결합된 구조이므로 레이어 간의 종속성은 상위 레이어에 대해 "무지"합니다.

인터페이스에 대한 디자인 아이디어를 레이어드 디자인에서 따른다면 이러한 하향 의존도 약한 의존이 되어야 합니다. 따라서 인터페이스 정의를 변경하지 않고 이상적인 계층형 아키텍처는 추출 가능성과 교체 가능성을 지원하는 "서랍" 아키텍처여야 합니다. 이로 인해 비즈니스 논리 계층의 디자인은 두 가지 다른 역할을 수행하므로 확장성을 지원하는 아키텍처에 특히 중요합니다.

데이터 액세스 계층의 경우 호출자이고 프레젠테이션 계층의 경우 호출 수신자입니다. 의존성과 의존성 사이의 관계는 비즈니스 로직 계층에서 얽혀 있습니다. 의존성 관계의 분리를 어떻게 실현할 것인지는 비즈니스 로직 구현 외에 디자이너에게 맡겨진 과제입니다.

데이터 계층

데이터 액세스 계층: 지속성 계층이라고도 하며 해당 기능은 주로 데이터베이스 액세스를 담당하며 데이터베이스 시스템, 바이너리 파일, 텍스트에 액세스할 수 있습니다. 문서 또는 XML 문서.

간단히 말하면 데이터 테이블에 Select, Insert, Up날짜, 삭제 작업을 구현하는 것입니다. ORM 요소를 추가하려는 경우 객체와 데이터 테이블 간의 맵핑과 객체 엔터티의 지속성이 포함됩니다.

장점 및 단점

장점

1. 개발자는 전체 구조 중 한 레이어에만 집중할 수 있습니다.

2. 원래 레이어 구현을 새로운 것으로 쉽게 교체할 수 있습니다.

3. 레이어 간의 종속성을 줄일 수 있습니다.

예. >

5. 각 레이어의 로직 재사용에 도움이 됩니다.

6. 구조가 깔끔해짐

7. 추후 유지관리시 유지관리 비용과 유지시간이 대폭 줄어듭니다

단점

1. 시스템 성능이 저하되었습니다. 이것은 자명합니다. 계층적 구조를 채택하지 않으면 많은 기업이 데이터베이스에 직접 접근해 해당 데이터를 얻을 수 있지만 이제는 중간 계층을 거쳐야 한다.

2. 계단식 수정으로 이어지는 경우도 있습니다. 이 수정은 특히 하향식 방향에 반영됩니다. 프리젠테이션 레이어에 기능을 추가해야 하는 경우 해당 디자인이 계층 구조를 따르도록 하기 위해 해당 비즈니스 로직 레이어와 데이터 액세스 레이어에 해당 코드를 추가해야 할 수도 있습니다.

3. 개발 비용 증가.

규칙

프로그램의 3계층 구조는 프로젝트가 DAL, BLL, WebUI의 세 가지 모듈로 나누어져 있다는 의미는 아닙니다. 레이어 다음 질문은 프로젝트 내부에 있습니다.

1. UILayer에는 SQL 문이나

저장 프로시저 호출이 적거나 없습니다. 데이터를 수정하려면?

2. UILayer를 제거해도 프로젝트가 인터페이스/

API 수준에서 모든 기능을 계속 제공할 수 있습니까?

3. 유사한 환경의 다른 프로젝트에 이식할 수 있습니까?

4. 세 가지 모듈을 서로 다른 서버에서 실행할 수 있습니까?

모든 대답이 '예'가 아니라면 귀하의 프로젝트는 세 가지- 3 레이어 프로그램에는 동의해야 할 몇 가지 규칙이 있습니다.

1. 가장 중요한 것은 UI 레이어는 셸로만 사용할 수 있으며 BizLogic 처리를 포함할 수 없다는 것입니다.

2. 디자인은 UI가 아닌 시작점부터 시작해야 합니다. BLL 레이어는 모든 BizLogic을 API에서

객체 지향 방식으로 구현해야 합니다. 🎜>3. 데이터 계층이 단순한 SqlHelper인지 아니면 매핑 클래스

인지 여부는 어느 정도 추상화 수준에서 시스템 독립적이어야 합니다.

4. >엔터프라이즈 서비스), 또는

원격 개체 기술과 같은 원격 개체 기술은 배포 중에 실제로 다른 서버에 배포되는지 여부에 관계없이 설계 시 최소한 이러한 고려 사항을 고려해야 합니다.

COM+(그래서 프로젝트에 3티어/다티어 디자인을 적용할지를 고려할 때 실제로 필요한지 여부를 먼저 고려해야 합니까? WebApplication을 여는 데 충분하며 전혀 할 필요가 없습니다. 매우 복잡한 Remoting,프로젝트 요구 사항WebService을 해결하기 위해 다층 구조가 사용됩니다.

과 MVC

의 차이점

MVC(Model-View-Controller)는 도메인 객체와 UI 프리젠테이션 레이어 객체를 구별하는 데 사용할 수 있는 디자인 패턴입니다.

또한 아키텍처 수준에서도 마찬가지입니다. 둘 다 프리젠테이션 레이어가 있다는 점이지만 차이점은 다른 두 레이어에 있습니다.

은 3티어 아키텍처에서 Controller의 개념을 정의하지 않습니다. 이것이 제가 생각하는 가장 다른 점입니다. MVC는 비즈니스 논리적 액세스를 두 계층으로 간주하지 않습니다. 이것이 3계층 아키텍처 또는 MVC를 사용하여 프로그램을 구축하는 것의 주요 차이점입니다. 물론. 3-Tier 아키텍처에서도 모델이 언급되지만, 3-Tier 아키텍처의 Model 개념은 MVC의 Model 개념과 다릅니다. "3-Tier"의 일반적인 Model 계층은 엔터티 클래스로 구성됩니다. , MVC에서는 비즈니스 로직과 액세스 데이터로 구성됩니다.

위 내용은 자바 3티어 아키텍처의 원리와 기능 요약(그림)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!