'Back-End'에 해당되는 글 135건

Static

a static member is a member of a class that isn't associated with an instance of a class. Instead, the member belongs to the class itself. As a result, you can access the static member without first creating a class instance

1. Example for static variable and methods

1_1. static variable

Static variables are belongs to the class and not to the object

1_2. static method

Static methods are also similar to static variable

1_3. Example

2. Example for static block

Static blocks are nothing but a normal block of code, enclosed in braces {}, preceded with static keyword.

These static blocks will be called when JVM loads the class into memory. Incase a class has multiple static blocks across the class, then JVM combines all these blocks as a single block of code and executes it

2_1. Example

3. Example for static block vs constructor

Java static blocks will be called when JVM loads the class into memory, means it will be called only once. But constructor will be called everytime when you create an object. 

3_1 Example

4. Example for Singleton class using static block

Since static block will be called only once, we can use static block to develop singleton class.

To create singleton class, make constructor as private, so that you cannot create object outside of the class. Create a private static variable of same class type, so that created object will be pointed to this reference. Now create static block, and create object inside static block. Since static block will be called only once, the object will be created only once.

4_1. Example

5. STATIC import

 We can access any static fields or methods with reference to the class name. Static imports allow us to import all static fields and methods into a class and you can access them without class name reference

5_1. Source

Application Architecture

- 아키텍처: 어떤 경계 안에 있는 내부 구성요소들이 어떤 책임을 갖고 있고, 어떤 방식으로 서로 관계를 맺고 동작하는지를 규정

1) 계층형 아키텍처

- 인터페이스와 같은 유연한 경계를 만들어두고 분리하거나 모아주는 작업이 필요하다.

(1) 아키텍처와 SoC

- 계층형 아키텍처(multi-tir-architectuer) : 책임과 성격이 다른것을 크게 그룹으로 만들어 분리해두는 것

- 웹 기반의 엔터프라이즈는 흔히 3계층 애플리케이션이라고함 

(2) 3계층 아키텍처와 수직 계층

- 3계층 아키텍처 : 데이터엑세스 계층, 서비스 계층, 프레젠테이션 계층

a. 데이터 엑세스 계층

- DAO 계층으로 불린다.

- 사용 기술에 따라 다시 세분화된 계층으로 구분

- 추상화 수준에 따른 구분으로 수직적인 계층이라고도 함

- ex) JdbcTemplate을 사용하는 DAO 계층

- JdbcTemplate이 추상화를 위한 계층으로 사용돼서 로우 레벨의 기반 계층에 존재하는 JDBC와 드라이버, 스프링의 트랜잭션 추상화 서비스의 동기화 기능을 간접적으로 이용하게 만듬

b. 서비스 계층

- DAO 계층을 호출하고 이를 활용해서 만들어진다.

- 데이터 엑세스를 위한 기능 외에 서버나 시스템 레벨에서 제공하는 기반 서비스를 활용할 필요도 있다.

- 추상화 수직 계층구조가 필요없다.

- 서비스 계층 코드가 기반 서비스계층의 구현에 종속되면 안된다.

- 백엔드, 데이터 엑세스 계층이 변경되더라도 그대로 유지되야함

c. 프레젠테이션 계층

- 가장 복잡하다. 다양한 기술과 프레임워크의 조화

- HTTP프로토콜을 처리하는 가장 기본 엔진 서블릿 기술을 바탕으로 한다.

(3) 계층형 아키텍처 설계의 원칙

- 각 계층은 응집도가 높으면서 다른 계층과는 낮은 결합도를 유지 해야한다.

a. 계층간의 설계 실수_1(서비스 계층에서 DAO호출시)

수정 전

public ResultSet findUsersByName(String name) throws SQLException;

- 데이터 엑세스 계층의 기술과 그역할을 다른 계층에 노출한다는 점

- 결과를 JDBC의 ResultSet으로 받음 -> 서비스 계층의 코드는 ResultSet이라는 데이터 엑세스 계층에서 만들어진 오브젝트를 직접 다뤄야함

- SQLException 이라는 JDBC기술 종속적인 예외를 사용하면 서비스계층에서는 SQLException을 해석해서 예외상황을 분석해야함

수정 후

public List<User> findUsersByName(String name) throws DataAccessException;

- 특정 계층에 종속되지 않는 단순한 오브젝트(User)의 형태로 전달해야함

- DataAccessException처럼 런타임 예외로 만듬 -> 그 존재를 무시할수 있도록

b. 계층간의 설계 실수_1(프레젠테이션 계층의 오브젝트를 그대로 서비스 계층의 전달)

- 서블릿의 HttpServletRequest, HttpServletResponse, HttpSession 같은 타입을 서비스 계층 인터페이스 메소드의 파라미터 타입으로 사용하면 안됨

- 계층의 경계를 넘어갈때는 반드시 특정 계층에 종속되지 않는 오브젝트 형태로 변환해야함

- 계층 사이의 낮은 결합도를 유지하며 계층사이의 호출은 인터페이스를 통해서만 이뤄져야 한다.

- 인터페이스를 사용한다는건? -> 각 계층의 경계를 넘어서 들어오는 요청을 명확히 하겠다는 뜻

- 한 계층의 내부에서만 쓰는 빈 오브젝트를 DI를 통해 다른 계층에서 함부로 쓰는 일을 피해야함

2)  애플리케이션 정보 아키텍처

- 엔터프라이즈 시스템은 동시에 많은 작업이 빠르게 수행됨

- 사용자의 요청을 처리하는 동안만 간단한 상태를 유지함

- 상태 정보 장기간보관: DB, 메인프레임 같은 EIS 백엔드 시스템에 저장

- 상태 정보 임시보관 : 클라이언트, 서버의 사용자별 세션

- 애플리케이션을 사이에 두고 흘러다니는 정보를 어떤 식으로 다룰지를 결정 하는 일도 아키텍처를 결정할때 중요한 기준이 됨

a. 정보를 데이터로 다루는 경우

- 애플리케이션에 흘러다니는 정보를 단수히 값이나 값을 담기위한 목적의 오브젝트 형태 취급

- 값을 그래도 프레젠테이션 계층, 즉 사용가자 보는 화면과 연결

- 핵심 비즈니스 로직을 어디에 두는지에 따라 DB에 무게를 두는 구조, 서비스 계층의 코드에 무게를 두는 구조로 나뉨

b. 정보를 오브젝트로 다루는 경우

(1) DB/SQL 중심의 로직 구현방식

- 데이터 중심 구조의 특징은 하나의 업무 트랜잭션에 모든 계층의 코드가 종속됨

a.단점

- 종속적이고 배타적이다, 다른 업무에 재사용하기 힘들다

- 업무의 내용이 바뀌면 모든 계층의 코드가 함께 변경된다

- SQL로직이 복잡해 질수 있다. 대부분의 코드가 중복되기 쉽다. 

- 서비스 계층이 의미가 없고 2계층 구조에서도 사용 가능

- 자바코드가 단지 DB와 웹 화면을 연결해주는 단순한 인터페이스 도구로 전락

b. 장점

- 개발이 쉽다.

- 툴이나 코드 생성기를 이용해 자동화 하기 쉽다.

- 개발자들 끼리 서로 간섭없이 자신에게 할당된 기능을 독립적으로 만드는데 편하다

(2) 거대한 서비스 계층(fat service layer)

- DB에 많은 로직을 두는 개발 방법을 피함

- 비즈니스 로직은 서비스 계층으로 옹겨와서 코드의 비중이 커지고 객체지향 개발의 장점을 살릴 수 있다. 

- SQL은 서비스 계층의 비즈니스 로직의 필요에 따라 만들어 지기 쉽다.

- 스파게티 코드가 될 수 있다.  중복발생과 장기적 코드 관리 힘들 수 있다.

3) 오브젝트 중심 아키텍처

- 도메인 모델을 방영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는데 사용한다는 것이다. 

- 오브젝트를 만들어두고 오브젝트 구조 안에 정보를 담아서 각 계층 사이에 전달하게 만드는 것이 오브젝트 중심 아키텍처이다.

(1). 데이터와 오브젝트 비교

a. 데이터 방식 

- DAO가 만드는 SQL의 결과에 모든 계층의 코드가 의존하게 된다.

- Category와 그에 대응되는 Product를 찾아 SQL을 이용해 조인한후 하나의 맵에 뭉뚱그려 가져옴

b. 오브젝트 방식

- 애플리케이션에 사용되는 정보가 도메인 모델의 구조를 반영해서 만들어진 오브젝트 안에 담긴다. 도메인 모델은 애플리케이션 전 계층에서 동일한 의미를 갖는다.

- DB에서 SQL 결과로 가져온 값을 그대로 사용하는 경우와는 다르게, 도메인 모데을 반영하는 오브젝트를 사용하면 자바의 특성을 살릴 수 있다.

- 테이블의 정보와 그 관계를 유지한채로 정확한 개수의 Category오브젝트와 그에 대응하는 Product오브젝틀 만들어 사용

- DB에 가져온 정보를 도메인 오브젝트 구조에 맞게 변환해야함

- DAO, 서비스 계층은 자신이 DB에서 가져와서 도메인 모델 오브젝트에 담아주는 정보가 어떤 업무 트랜잭션에서 어떻게 사용될지 신경 안써도됨

(2). 도메인 오브젝트를 사용하는 코드

- 오브젝트 중심 방식의 비즈니스 로직 예

- 만약 데이터 중심이였다면 이런 식의 재사용 가능한 메소드를 만드는게 쉽지 않다.

(3). 도메인 오브젝트 사용의 문제점

- 성능면에서 데이터 방식 보다 떨어질 수 있다.

- DAO는 비즈니스 로직의 사용방식을 알지 못하므로, 도메인 오브젝트의 모든 필드 값을 다 채워서 전달 해야함(안쓰는 오브젝트 낭비 발생)

- ORM과 같은 데이터 액세스 기술을 사용하는 것을 권장한다.

- JDBC를 사용한다면 지연된로딩(lazy loading)기법을 사용

(4). 빈약한 도메인 오브젝트 방식

- 빈약한(anemic) 오브젝트 : 도메인 오브젝트에 정보만 담겨 있고, 정보를 활용하는 아무런 기능도 갖고 있지 않은 것

- 흔히 사용하는 방식중 하나

- 빈약한 오브젝트 방식에서는 비즈니스 로직이 서비스 계층에 존재한다.

- 데이터 중심 아키텍처의 거대 서비스 계층 구조와 비슷

- SQL에 의존적인 데이터 방식보다는 휠씬 유연하고 간결하다

- 서비스 계층의 메소드에 대부분의 비즈니스 로직이 들어 있기 때문에 로직의 재사용성이 떨어 지고 중복 발생이 쉽다.  

- 비즈니스 로직이 복잡하지 않다면 아주 유용한 방법

(5). 풍성한 도메인 오브젝트(rich domain object), smart domain object

- 빈약한 도메인 오브젝트의 단점을 극복하고 객체지향적인 특징을 살림

- 어떤 비즈니스 로직은 측정 도메인 오브젝트나 그 관련 오브젝트가 가진 정보과 깊은 관게가 있고 이런 로직을 서비스 계층의 코드가 아니라 도메인 오브젝트에 넣고 서비스 계층의 비즈니스 로직에서 재사용( 응집도를 높임)

- 훨씬 간결하고 객체지향적이다 .

- 스프링의 빈으로 관리되는 3계층의 오브젝트들은 도메인 오브젝트를 자유롭게 이용할 수 있지만 그 반대는 안 됨

- 시스템이 복잡할때 적합

(6). 도메인 계층 방식

- DB에서 가져와 변경된 정보를 다시 DB에 반영하려면 서비스 계층 오브젝트의 부가적인 작업이 필요

- 3계층의 오브젝트를 DI 받아서 직접 사용??? 가능?? -> 도메인 계층 방식 등장

- 기존 3계층과 같은 레벨로 격상된다. 서비스 계층과 데이터 액세스 계층의 사이에 존재

- 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층의 오브젝트 안에서 진행

- 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용? ->

-> 스프링이 관리하지 않는 도메인 오브젝트에 DI를 적용하기 위해 AOP가 필요

- 도메인 계층사용시 선택 방법

- 여전히 모든 계층에서 도메인 오브젝트를 사용하게 한다.

-> 주의 안하면 심각한 혼란을 초래

- 도메인 오브젝트는 도메인 계층을 벗어나지 못하게 하는것

->  안전하지만 번거로울 수 있다.

- 매우 복잡하고 변경이 잦은 도메인을 가졌을 때 사용 권장

The Source of post is Spring of Toby3

1. Java enterprise Platform and Spring

- 자바 언어를 사용하는 모든 종류의 프로젝트라면 스프링으로 가능하다

- 주로 자바 엔터프라이즈 환경을 목적으로 한다.

1) 클라이언트와 백엔드 시스템

(1). DB를 사용하는 웹어플리케이션(기본 구조)

(2). 백엔드로는 DB는 물론 메시징서버, 메일서버, 메인프레임도 가능

2) 애플리케이션 서버

- 스프링으로 만든 애플리케이션을 자바 서버환경에 배포하려면 JavaEE 서버가 필요함

(1). 경량급 WAS/서블릿 컨테이너

- 톰켓, 제티

(2). WAS

- 안정적, 비쌈

3) 스프링 애플리케이션의 배포 단위

- 스프링으로 만든 어플리케이션은 다음 세가지로 배포가능

(1) 독립 웹 모듈

a. war로 패키징된 독립 웹 모듈로 배포 -> 톰캣 같은 서블릿 컨테이너면 이게 유일한 방법

b. 단순, 편함

(2) 엔터프라이즈 어플리케이션

a. 확장자가 car인 엔터프라이즈 애플리케이션

(3) 백그라운드 서비스 모듈

a. rar패키징 방법

soucre of post is Spring of Toby3

4. Skill of Spring

- 스프링에는  POJO프로그래밍을 손쉽게 할 수 있도록 지원하는 세가지 가능 기술( enaling technology)을 제공한다.

- IoC/DI, AOP, PSA

1) 제어의 역전(Ioc)/  의존관계 주입(DI)

- DI 사용이유 : 유연한 확장이 가능하게 하기 위함

- A -> B : 확장은 B가 자유롭게 변경될 수 있음, B가 변경돼도  A는 아무런 영향을 받지 않고 그대로 유지 가능

(1) DI의 활용방법

a. 핵심기능의 변경

- 대표적인 적용방법은 의존 대상의 구현을 바꾸는것 (전략패턴)

- A -> B 구조에서 A의 기능 일부를  B에게 위임한다고 했을 때 B의 구현 방식을 필요에 따라 통째로 B1, B2 처럼 통째로 변경

- 예) 서비스 오브젝트가 사용하는  DAD 의 구현 변경-> JDBC, JPA, 하이버네이트,   iBatis  등으로 통째로 변경 

b. 핵심기능의 동적인 변경

- 일반적인  DI와 다르게 동적으로 매번 다르게 변경 가능

- 예 : 사용자의 등급에 따라서 다르게 DataSource를 사용하게 만들 수도 있다.

- Dao -> DataSource :  Dao하나가 여러개의 DataSource에 의존하게 만들 수 있다.

- VIP에 속한 사용자의 등급에 따라서 그때그때 다른 DataSource를 DAO가 사용하게 함(더 빠르게)

- 다이내믹 라우팅 프록시, 프록시 오브젝트 기법을 활용

c. 부가기능의 추가

- 핵심기능은 그래도 둔 채로 부가기능을 추가(데코레이터 패턴)

- 인터페이스를 두고 사용하게 하고, 실제 사용할 오브젝트는 외부에서 주이하는  DI를 적용해두면 데코레이터 패턴을 쉽게 적용

 d. 인터페이스의 변경

- 클라이언트가 사용하는 인터페이스와 실제 오브젝트 사이에 인터페이스가 일치하지 않는 경우에도 DI유용

- 예 : A가 C오브젝트를 사용하려 한다고 가정 BUT  A -> B 인터페이스만 사용하도록 만들어짐, C는 B인터페이스 구현 안되어있다. 

- A가 DI를 통해 B의 구현 오브젝트를 받도록 만들어져 있다면 -> B 인터페이스를 구현했으면서 내부에서 C를 호출 해주는 기능을 가진 어댑터 오브젝트를 만들어 A에 DI 하면됨

-A -> B(C로위임) -> C

- 좀더 응용하면 PSA(서비스 추상화)

e. 프록시

- 프록시 패턴

- 필요한 시점에서 실제 사용할 오브젝트를 초기화하고 리소스를 준비하게 해주는 지연된 로딩(lazy loading)을 적용 하기위한 방법

- 원격 프로시(원격 오브젝트를 로컬처럼 사용할때)

f. 템플릿과 콜백

- 항상 고정적인 작업흐름과 그사이에서 자주 바뀌는 부분을 분리해서 템플릿과 콜백으로 만들고 이를  DI 원리를 응용해 적용하면 지저분한게 매번 만들어야 하는 코드를 간결하게 만듬

g. 싱글콘과 오브젝트 스코프

- DI가 필요한 이유중 한가지는  DI할 오브젝트의 생명주기를 제어 할 수 있다는 것임.

- 전통적인 싱글톤방식보단 IOC방식이 유용하다.

- 스프링 DI는 기본적으로 싱글톤으로 오브젝트를 만들어서 사용

- 스프링에서는 싱글콘 외에도 다양한 스코프를 갖는 오브젝트를 만들어  DI에 사용 할수도있다.

- HTTP 요청당 하나의 오브젝트를 만들거나 HTTP세션단 하나씩 오브젝트가 만들어 질 수 있다.

h. 테스트

- 여타 오브젝트와 협력해서 동작하는 오브젝트를 효과적으로 테스트하는 방법은 가능한 고립시키는 것임

- 다른 오브젝트와 사이에서 일어나는 일을 테스트를 위해 조작할 수 있도록 만든다.

- 스텁, 또는 목 오브젝트 같은 테스트 대역을 활용

- DI를 위해 만든 수정자 메소드를 사용하면 테스트 코드 안에서 수동으로 목 오브젝트를 주입 할수 있다. 

2) 에스펙트 지향 프로그래밍(AOP)

- AOP와 OOP는 서로 배타적이 아니다.

- IOC/DI를 이용하여 POJO에 선언적인 엔터프라이즈 서비스를 제공할 수 있지만 일부 서비스는 순수한 객체지향 기법만으로는 POJO의 조건을 유지한 채로 적용하기 힘듬

- AOP는 객체지향 기술의 한계와 단점을 극복 하도록 도와주는 프로그램

(1) AOP의 적용 기법

- AOP를 자바 언어에 적용하는 기법은 크게 두가지로 분류함

a. 스프링과 같이 다이내믹 프록시를 사용하는 방법

- 기존 코드에 영향을 주지 않고 부가기능을 적용하게 해주는 데코레이터 패턴을 응용

- 자바의 객체지향 패턴을 활용, 만들기 쉽고 적용 편리

- 부가기능을 부여할 수 있는 곳이 메소드의 호출이 일어나는 지점뿐이라는 제약

b. 자바 언어의 한계를 넘어서는 언어의 확장을 이용

- AspectJ라는 AOP툴이 존재

- AspectJ는 프록시 방식의 AOP에서는 불가능한 다양한 조인 포인트를 제공, 메소드호출뿐 아니라 인스턴스 생성, 필드 엑세스, 특정 호출 경로를 가진 메소드 호출 등에도 부가기능 추가

(2) AOP의 적용단계

- AOP는 하나의 모듈이 수많은 오브젝트에 보이지 않게 적용되기 때문에 매우 주의해서 사용해야한다.

a. AOP적용 1단계: 미리 준비된 AOP 이용

-  스프링이 제공하는 대표 AOP는 트랜잭션

- DB를 사용하는 애플리케이션이면 트랜잭을 필요로 하니 적용해서 AOP를 관찰

- @Configurable 애노테이션을 이용해서 도메인 오브젝트에 DI를 자동적해주는 AOP기능

b. AOP적용 2단계: 전담팀을 통한 정책 AOP 적용

- 소수의 AOP 전담팀을 가짐

- 오브젝트보안,  특정계층의 오브젝트를 이용 전후의 작업 기록을 남기는 로깅 등

c.AOP 적용 3단계: AOP의 자유로운 이용

- 1단계와 2단계를 거치고 익숙해지면 이제 개발자 스스로 활용

3) 포터블 서비스 추상화(PSA)

-  환경과 세부 기술의 변화에 관계없이 일관됭 방식으로 기술에 접근 할 수 있게 해주는  PSA이다

- 스프링은  JavaEE기술에 의존적일 수 밖에 없다. -> POJO? -> PSA 활용

- 트랜잭션 서비스 추상화 : 코드를 이용해 트랜잭션을 제어하지 않는다면 직접 이용할 이유가 없다. -> AOP를 이용하기 때문 -> 대신 구체적인 서비스 클래스를 빈으로 등록

soucre of post is Spring of Toby3