sourcecode

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

copyscript 2022. 9. 17. 09:51

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

Java 기반의 웹 애플리케이션 아키텍처를 공유합시다!

Java를 사용하여 구현되는 웹 애플리케이션에는 다양한 아키텍처가 있습니다.이 질문에 대한 답변은 다양한 웹 애플리케이션 설계의 라이브러리와 같은 장점과 단점이 될 수 있습니다.저는 답이 주관적일 것이라는 것을 알고 있지만, 가능한 한 객관적이고 우리가 나열하는 장단점에 동기를 부여하도록 노력합시다.

아키텍처를 설명하는 데 필요한 세부 수준을 사용합니다.답변이 가치가 있으려면 적어도 설명하는 아키텍처에서 사용되는 주요 기술과 아이디어를 설명해야 합니다.마지막으로 귀사의 아키텍처를 언제 사용해야 합니까?

제가 먼저...

아키텍처의 개요

Java EE, Java Persistence API, Servlet 및 Java Server Pages와 같은 Sun의 개방형 표준을 기반으로 하는 3계층 아키텍처를 사용합니다.

고집
비지니스
발표

계층 간의 가능한 통신 흐름은 다음과 같습니다.

Persistence <-> Business <-> Presentation

예를 들어 프레젠테이션 계층은 호출하거나 지속성 작업을 수행하지 않으며 항상 비즈니스 계층을 통해 작업을 수행합니다.이 아키텍처는 고가용성 웹 애플리케이션의 요구를 충족시키는 것을 목적으로 합니다.

고집

Create, Read, Update and Delete(CRUD; 작성, 읽기, 업데이트 및 삭제) 지속성 작업을 수행합니다.이 예에서는 (Java Persistence API) JPA를 사용하고 있으며 현재 지속성 공급자로 Hibernate를 사용하고 있으며 Entity Manager를 사용하고 있습니다.

이 계층은 여러 클래스로 나뉘며, 각 클래스는 특정 유형의 엔티티(즉, 쇼핑 카트와 관련된 엔티티는 단일 지속성 클래스에서 처리될 수 있음)를 처리하며, 한 명의 관리자만 사용합니다.

또한 이 계층은 다음과 같은 JPA 엔티티를 저장합니다.Account,ShoppingCartsyslog.

비지니스

웹 어플리케이션 기능과 관련된 모든 로직은 이 레이어에 있습니다.이 기능은 신용카드를 사용하여 온라인으로 제품을 결제하려는 고객을 위해 송금을 시작할 수 있습니다.웹 기반 게임에서 새 사용자를 만들거나 사용자를 삭제하거나 전투 결과를 계산하는 것과 마찬가지입니다.

있으며, .@StatelessStateless Session Bean(SLSB; 스테이트리스 세션빈)이 됩니다.각 SLSB는 매니저라고 불리며, 예를 들어 매니저는 코멘트 첨부 클래스가 될 수 있습니다.AccountManager.

AccountManager는 CRUD CRUD의 인스턴스에 합니다.CRUDAccountManagerPersistence지속성 레이어 내의 클래스입니다. 되어 있는 두 가지 .AccountManager하다

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

컨테이너 매니저 거래를 이용하기 때문에 거래 구분은 본인이 할 필요가 없습니다.기본적으로 SLSB 메서드를 시작할 때 트랜잭션을 시작하고 메서드를 종료하기 직전에 트랜잭션을 커밋(또는 롤백)합니다.이는 구성에 대한 관습의 한 예이지만 아직 기본값인 Required 이외에는 필요하지 않습니다.

다음은 Sun의 Java EE 5 튜토리얼에서 엔터프라이즈 JavaBeans(EJB)의 필수 트랜잭션 특성을 설명하는 방법입니다.

클라이언트가 트랜잭션 내에서 실행 중이며 Enterprise bean의 메서드를 호출하는 경우 메서드는 클라이언트의 트랜잭션 내에서 실행됩니다.클라이언트가 트랜잭션과 연결되지 않은 경우 컨테이너는 메서드를 실행하기 전에 새 트랜잭션을 시작합니다.

필수 속성은 컨테이너 관리 트랜잭션 구분과 함께 실행되는 모든 엔터프라이즈 bean 메서드에 대한 암묵적인 트랜잭션 속성입니다.일반적으로 다른 트랜잭션 속성을 재정의해야 하는 경우가 아니면 필수 속성을 설정하지 않습니다.트랜잭션 속성은 선언적이므로 나중에 쉽게 변경할 수 있습니다.

발표

우리의 프레젠테이션 층은...을 담당한다.프레젠테이션!사용자 인터페이스를 담당하며 HTML 페이지를 구축하고 GET 및 POST 요청을 통해 사용자 입력을 수신하여 사용자에게 정보를 표시합니다.현재 구 Servlet + Java Server Pages(JSP) 조합을 사용하고 있습니다.

이 계층은 비즈니스 계층의 관리자를 호출하여 사용자가 요청한 작업을 수행하고 웹 페이지에 표시할 정보를 받습니다.비즈니스 계층에서 수신되는 정보가 다음과 같이 덜 복잡한 유형일 수 있습니다.String »integers 및 다른 경우 JPA 엔티티.

아키텍처의 장점과 단점

장점

이 계층에서 영속성을 유지하는 특정 방법과 관련된 모든 것이 있다는 것은 비즈니스 계층에서 아무것도 다시 쓸 필요 없이 JPA를 사용하는 것에서 다른 것으로 바꿀 수 있다는 것을 의미합니다.
프레젠테이션 레이어를 다른 것으로 바꾸는 것은 간단합니다.더 나은 것을 발견하면 그렇게 될 가능성이 높습니다.
EJB 컨테이너가 트랜잭션 경계를 관리하도록 하는 것은 좋은 일입니다.
Servlet + JPA의 사용은 (처음부터) 간단하며, 테크놀로지는 많은 서버에서 널리 사용되고 구현됩니다.
Java EE를 사용하면 로드 밸런싱과 페일오버를 갖춘 고가용성 시스템을 쉽게 만들 수 있습니다.둘 다 우리가 꼭 가져야 한다고 느끼고 있어요.

단점

를 JPA를 할 수 .@NamedQueryJPA를 사용하다당사의 아키텍처와 같이 지속성 클래스에 가능한 한 많은 지속성과 관련된 항목이 있는 경우 JPA 엔티티를 포함하는 쿼리를 찾을 수 있는 위치가 펼쳐집니다.지속성 연산의 개요는 더욱 어려워지고, 따라서 유지보수가 어려워집니다.
JPA를 사용하다 ★★★★★★★★★★★★★★★★★.Account ★★★★★★★★★★★★★★★★★」ShoppingCart즈니니 ?상 ?? ????이 방법은 이러한 클래스를 터치하여 JPA가 처리하는 방법을 알고 있는 엔티티로 변환해야 하기 때문입니다.
비즈니스 객체이기도 한 JPA 엔티티는 데이터 전송 객체(DTO)와 같이 생성되며 가치 객체(VO)라고도 합니다.그 결과 비즈니스 객체는 접근자 메서드 이외에는 독자적인 로직이 없기 때문에 도메인 모델이 빈약해집니다.모든 논리는 비즈니스 계층의 매니저에 의해 이루어지기 때문에 보다 절차적인 프로그래밍 스타일이 됩니다.오브젝트 지향적인 디자인은 좋지 않지만, 문제는 아닐까요?(결국 객체 지향만이 결과를 가져온 유일한 프로그래밍 패러다임은 아닙니다.
EJB와 Java EE를 사용하면 다소 복잡해집니다.또한 Tomcat만 사용할 수 없습니다(EJB 마이크로 컨테이너를 추가하는 것은 Tomcat만 사용할 수 있는 것이 아닙니다.
Servlets + JPA 사용에는 많은 문제가 있습니다.이러한 문제에 대한 자세한 내용은 Google을 사용하십시오.
에서 정보를 수 사용).fetch=FetchType.LAZY프레젠테이션 레이어 내부에서).예외가 트리거됩니다.이러한 필드를 포함하는 엔티티를 반환하기 전에 반드시 관련 getter에 문의해야 합니다.다른 옵션은 Java Persistence Query Language(JPQL)를 사용하여FETCH JOIN그러나 이 두 가지 옵션 모두 조금 번거롭습니다.

좋아, 내가 (짧게) 하나 할게.

프런트 엔드 : 태피스트리 (구 프로젝트의 경우 3개, 신 프로젝트의 경우 5개)
비즈니스 레이어: 봄
DAO: Ibatis
데이터베이스: Oracle

NAT은 스핑 트랜잭션 지원을 사용하며, 서비스 계층에 진입하면 트랜잭션을 시작하여 DAO 호출로 전파합니다.서비스 계층은 가장 많은 비즈니스 모델 지식을 보유하고 있으며 DAO는 비교적 단순한 CRUD 작업을 수행합니다.

일부 더 복잡한 쿼리 작업은 성능상의 이유로 백엔드의 더 복잡한 쿼리에 의해 처리됩니다.

이 경우 Spring을 사용하는 장점은 Spring Proxy 클래스의 배후에 있는 국가/언어 의존 인스턴스를 가질 수 있다는 것입니다.세션의 사용자를 기반으로 콜을 실행할 때 올바른 국가/언어 구현이 사용됩니다.

트랜잭션 관리는 거의 투명하며 런타임 예외 시 롤백됩니다.가능한 한 체크되지 않은 예외를 사용합니다.이전에는 체크된 예외를 실시했습니다만, 스프링의 도입으로 체크되지 않은 예외의 장점을 알 수 있었습니다.예외는 가능한 경우에만 취급할 수 있습니다.많은 보일러 플레이트 "잡기/재투기" 또는 "쓰레기"를 피할 수 있습니다.

투고보다 짧아서 죄송합니다.재미있기를바랍니다...

현재 이상적인 Java 기반 웹 개발 기술.

웹 계층:

HTML+CSS+Ajax+JQuery

RESTFul Web 컨트롤러/액션/요구 처리 계층:

플레이 프레임워크

비즈니스 로직/서비스 계층:

Pure Java Code는 가능한 길게 사용합니다.웹 서비스 퓨전도 이곳에서 할 수 있다.

XML/JSON 데이터 변환 레이어:

XMLTool(Google 코드로 검색),JSoup, Google GSon, XStream,JOOX(구글 코드로 검색)

지속성 레이어:

CRUD: JPA 또는 Siena Project 또는 QueryDSL/복잡한 쿼리: JUQ, QueryDSL

5센트 여기 있습니다.

발표

안드로이드, 앵글JS Web Client, OAUTHv2

API

REST, Jersey(JAX-RS), Jackson(JSON 직렬화 해제), DTO 객체(비즈니스 로직 모델과 다름)

비즈니스 로직

DI 및 이벤트 처리용 스프링.모델 객체에 대한 DDD식 접근법.장시간 실행 중인 작업은 작업자 모듈의 SQS로 오프로드됩니다.

DAO

엔티티를 저장하는 Spring JDBC 템플릿이 있는 저장소 모델.리더보드용 Redis(JEDIS), 순서 목록 사용.토큰 스토어의 메모리 캐시.

데이터베이스

MySQL, Memcached, Redis

이 프로젝트에서 우리가 지켜본 것은 다음과 같습니다.

프론트 엔드 테크놀로지

각도 JS
HTML5
css3
자바스크립트
부트스트랩 3

API

쉬다
저지(JAX-RS)
안심하세요.
스프링 부츠
잭슨
스프링 보안

비즈니스 로직

스프링 데이터
스프링 데이터 MongoDB

데이터베이스

MongoDB

서버(캐시용)

리다이

우리는 여전히 일반적인 Struts-Spring-Hibernate 스택을 사용하고 있습니다.

향후의 앱에서는, Spring Web Flow + Spring MVC + Hibernate 또는 Spring + Hibernate + Web Services(Flex 프런트 엔드를 탑재한 Web 서비스)를 검토하고 있습니다.

델 아키텍처의 특징 중 하나는 모듈화입니다.데이터베이스에는 3~최대 30개의 테이블로 시작하는 모듈도 있습니다.대부분의 모듈은 비즈니스 및 웹 프로젝트로 구성됩니다.비즈니스 프로젝트는 비즈니스 및 지속성 논리를 유지하고 웹은 프레젠테이션 논리를 유지합니다.
논리 레벨에서는, 다음의 3개의 레이어가 있습니다.★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
★★★★★★★★★★★★★★★★★★:
프레젠테이션은 비즈니스와 지속성에 따라 달라집니다.
이치노
비즈니스는 다른 계층에 의존하지 않습니다.

대부분의 비즈니스 프로젝트에는 3종류의 인터페이스가 있습니다(주의: GUI가 아닌 프로그래밍형 Java 인터페이스 레이어).

프레젠테이션이 클라이언트로 사용하는 인터페이스
다른 모듈이 모듈의 클라이언트일 때 사용하는 인터페이스.
모듈의 관리 목적으로 사용할 수 있는 인터페이스.

보통 1은 2를 확장합니다.이렇게 하면 모듈 구현 중 하나를 다른 구현으로 쉽게 교체할 수 있습니다.이를 통해 다양한 고객을 채택하고 보다 쉽게 통합할 수 있습니다.일부 고객은 특정 모듈만 구입하므로 이미 보유하고 있는 기능을 통합해야 합니다.인터페이스와 실장 레이어는 분리되어 있기 때문에 의존 모듈에 영향을 주지 않고 특정 클라이언트에 애드혹모듈 구현을 쉽게 전개할 수 있습니다.Spring Framework를 사용하면 다른 구현을 쉽게 구현할 수 있습니다.

우리의 비즈니스 계층은 POJO를 기반으로 합니다.제가 관찰하고 있는 경향 중 하나는 이러한 POJO가 DTO와 유사하다는 것입니다.우리는 빈혈 도메인 모델로 고통받고 있다.왜 이런 일이 일어나는지는 잘 모르겠습니다만, 많은 모듈의 문제 영역이 단순하기 때문일 수 있습니다.작업의 대부분은 CRUD이거나 개발자가 로직을 다른 곳에 배치하는 것을 선호하기 때문입니다.

다음은 제가 작업한 웹 아키텍처입니다.

주요 요구사항 중 하나는 애플리케이션이 모바일/기타 장치를 지원해야 한다는 것이었습니다.또한 응용 프로그램은 테크놀로지 선택의 변화에 따라 확장 가능하거나 유연해야 합니다.

프레젠테이션 계층:

JSP/JQuery(클라이언트측 MVC)
네이티브 안드로이드
네이티브 아이폰
모바일 웹(HTML5/CSS3/응답형 설계)
스프링 REST 컨트롤러(JAX-RS로 변경 가능)

비즈니스 서비스 계층:

Spring @Service(스테이트리스 EJB로 변경 가능)

데이터 액세스 계층:

Spring @Repository (스테이트리스 EJB로 변경 가능)

자원 계층:

휴지 상태(JPA) 엔티티(임의의 ORM으로 변경 가능)

이 아키텍처에 이은 책에 대한 자세한 내용은 여기를 참조하십시오.

IMHO야, 우리 대부분은 공통분모를 가지고 있어.적어도 백엔드에는 어떤 형태의 IOC/DI 컨테이너와 지속성 프레임워크가 있습니다.개인적으로 나는 이것을 위해 Guice와 Mybatis를 사용한다.차이점은 뷰/UI/프레젠테이션 계층을 구현하는 방법에 있습니다.여기에는 크게 두 가지 옵션이 있습니다(더 많을 수 있습니다).액션 베이스(컨트롤러에 매핑된 URL) 및 컴포넌트 베이스.현재 컴포넌트 기반 프레젠테이션 레이어(위킷 사용)를 사용하고 있습니다.URL 및 컨트롤러가 아닌 컴포넌트와 이벤트를 사용하는 데스크톱 환경을 완벽하게 모방합니다.현재 이 URL 컨트롤러의 아키텍처로 이행해야 하는 이유를 찾고 있습니다(이렇게 해서 이 페이지를 작성하게 되었습니다).RESTful 및 Stateless 아키텍처에 대한 과대 광고 이유

간단히 말하면, 저는 Guice IOC 컨테이너 위에 컴포넌트 지향 프레임워크를 사용하여 스테이트풀한 웹 애플리케이션을 작성하고 Mybatis를 사용하여 데이터를 관계형 데이터베이스에 저장합니다.

조금 다르긴 하지만 모듈러형 자바 아키텍처가 더 좋다고 생각합니다.다음과 같은 것이 있습니다.

스프링 WS/Rest/JSP 프론트 엔드
비즈니스 서비스 로직을 위한 스프링 MVC(프레젠테이션 레이어 로직 및 스프링 트랜잭션 포함)
EJB를 통해 비즈니스 서비스에서 조회되는 구성 요소 서비스 통신 인터페이스입니다.EJB는 스프링 트랜잭션에 참여할 수 있는 자체 트랜잭션 경계를 설정합니다.
컴포넌트 서비스 구현, 스프링 컴포넌트
통합 레이어, 데이터베이스 통합용 MyBatis, 웹 서비스 통합용 Spring WS, 기타 서비스 통합 기술
메인프레임, 데이터베이스, 다른 서버에서의 기타 서비스...

상기 외에 공유 라이브러리 모듈이 있으며, 공유 라이브러리 모듈은 모든 소프트웨어에서 공통 라이브러리 모듈은 공통적인 기능을 제공합니다.

서로 다른 계층을 사용함으로써 완전한 디커플링과 필요한 모듈화를 실현할 수 있습니다.봄뿐만 아니라 Java EE의 파워도 충분히 활용할 수 있습니다.예를 들어, 필요한 경우 프런트 엔드에 JSF를 사용하는 것을 방해하는 것은 없습니다.

OP의 건축 예시와 비교하면, 반전이 있긴 하지만, 3개의 주요 레이어가 아닌 4개의 레이어라고 할 수 있다고 생각합니다.

저는 경직된 매니저 패턴을 이용한 프로젝트를 해왔습니다.역사적으로, 저는 모든 것이 깔끔한 상자에 들어가는 엄격한 계층의 큰 지지자였습니다.내 경력이 발전함에 따라 나는 많은 경우에 그것이 강요된다는 것을 알게 되었다.애플리케이션 설계에 대해 보다 민첩한 사고방식을 채택하면 더 나은 제품이 탄생한다고 생각합니다.이것이 의미하는 것은 당면한 문제를 해결하는 일련의 클래스를 만드는 것입니다."이것저것 매니저를 만들었나요?"라고 말하는 것보다

현재 작업 중인 프로젝트는 Spring MVC와 RestEasy JSON/Ajax 콜을 조합한 웹 앱입니다.당사의 컨트롤러에 내장된 서버 측에는 직접 데이터베이스 액세스, 일부 EJB 액세스 및 일부 SOAP 기반 웹 서비스 호출을 위한 JPA/Hibernate를 갖춘 합리적인 파사드 기반 데이터 계층이 있습니다.이 모든 것은 JSON으로 시리얼화하여 클라이언트에 반환할 대상을 결정하는 커스텀 Java 컨트롤러 코드입니다.

Unix 설계 철학의 "Worse is Better" 아이디어를 채택하는 대신 통합 패턴을 만드는 데 거의 시간을 들이지 않습니다.라인 밖으로 색을 칠하고 센스 있는 것을 만드는 것이 엄격한 디자인 명령을 따르는 것을 만드는 것보다 훨씬 낫기 때문입니다.

웹 애플리케이션아키텍처의 컴포넌트는 다음과 같습니다.

1 : 브라우저 : 클라이언트와의 대화

        HTML
        JavaScript
        Stylesheet

2 : 인터넷

3 : 웹 서버

        CSS
        Image
        Pages(Java render )

4 : 응용 프로그램서버

        App Webapp (Java interaction)
        Others WebApps

5 : 데이터베이스 서버

        Oracle, SQL, MySQL

6 : 데이터

언급URL : https://stackoverflow.com/questions/286846/describe-the-architecture-you-use-for-java-web-applications

'sourcecode' 카테고리의 다른 글

Java 또는 C#에서의 예외 관리 베스트 프랙티스 (0)	2022.09.17
UNIX 소켓 파일용 mysqld_safe 디렉토리 '/var/run/mysqld'가 없습니다. (0)	2022.09.17
val()과 text()의 차이 (0)	2022.09.17
Maven이 모든 테스트를 실행하도록 하는 것, 심지어 일부 실패 시에도 (0)	2022.09.17
자동 열은 하나만 있을 수 있습니다. (0)	2022.09.17

현재글Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

각종 프로그래밍 정보를 다루는 블로그입니다.

Python, WordPress, Git, jquery, JSON, angularjs, Spring-Boot, php, reactjs, C, MySQL, JavaScript, MariaDB, Java, vuex, Powershell, Ajax, mongoDB, oracle, vuejs2,

Today :
Yesterday :

일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

copyscript

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

아키텍처의 개요

고집

비지니스

발표

아키텍처의 장점과 단점

장점

단점

웹 계층:

RESTFul Web 컨트롤러/액션/요구 처리 계층:

비즈니스 로직/서비스 계층:

XML/JSON 데이터 변환 레이어:

지속성 레이어:

발표

API

비즈니스 로직

DAO

데이터베이스

'sourcecode' 카테고리의 다른 글

'sourcecode'의 다른글

티스토리툴바

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

Java 웹 응용 프로그램에 사용하는 아키텍처에 대해 설명하십시오.

아키텍처의 개요

고집

비지니스

발표

아키텍처의 장점과 단점

장점

단점

웹 계층:

RESTFul Web 컨트롤러/액션/요구 처리 계층:

비즈니스 로직/서비스 계층:

XML/JSON 데이터 변환 레이어:

지속성 레이어:

발표

API

비즈니스 로직

DAO

데이터베이스

'sourcecode' 카테고리의 다른 글

'sourcecode'의 다른글

관련글

티스토리툴바