vo/dto차이

VO(Value Object)
:값 그 자체를 표현하는 객체

• 로직을 포함할 수 있으며, 객체의 불변성(객체의 정보가 변경하지 않음)을 보장

• 서로 다른 이름을 갖는 VO 인스턴스더라도 모든 속성 값이 같다면 두 인스턴스는 같은 객체라고 할 수 있다**

• 이를 위해 VO에는 Object클래스의 equals()와 hashCode()를 오버라이딩 해야한다

DTO(Data Transfer Object)
: 계층(Layer) 간 데이터 교환을 위해 사용하는 객체

• 데이터 교환만을 위해 사용하므로 로직을 갖지않고, getter/setter 메소드만 갖는다

즉 , 로직은 없고 데이터를 담고 ,꺼내는 getter/setter 메소드만 남는다

Entity
:실제 DB의 테이블과 매핑되는 객체
**- id를 통해 각각의 Entity를 구분

• vo와 마찬가지로 로직을 가질수 있다 **

정리하면
DTO는 계층간 데이터 이동을 위해 사용되는 객체
vo는 값을 갖는 순수한 도메인
Entitiy는 이를 DB 테이블과 매핑하는 객체

java 빈즈?

자바 빈즈?
:큰 프로그램에서 독립적으로 수행되는 하나의 작은 프로그램 부품을 컴포넌트 비즈니스 로직 부분을 담당하는 자바 프로그램 단위

장점 :

• JSP 페이지가 복잡한 자바 코드로 구성되는것을 피한다
• JSp 페이지에는 HTMl코드와 쉽고 간단한 자바코드만.
• 어려운 코드를 분리
• 여러 응용 프로그램에서 재사용 가능 ( 마치 상속하는것 처럼)**

StringBuffer랑 StringBuilder 차이

가장 큰 차이점은
"동기화의 유무"

StringBuffer
동기화 키워드를 지원하여 멀티쓰레드 환경에서 안전하다
고로 String도 불변성을 가지기 때문에 마찬가지로 멀티쓰레드 환경에서의 안정성 가짐

StringBuilder
동기화 지원하지 않기 떄문에 멀티쓰레드 환경에서 사용하는 것은 적합하지 않지만 동기화를 고려하지 않는 만큼 단일 쓰레드에서 StringBuffer보다 뛰어나다

정리
String : 문자열 연산이 적고 멀티쓰레드 환경일 경우
StringBuffer : 문자열 연산이 많고 멀티쓰레드 환경일 경우
StringBuilder : 문자열 연산이 많고 단일쓰레드이거나 동기화를 고려하지 않아도 되는 경우

모델 1 모델 2 차이

모델1
: 비즈니스 로직 영역(Controller(에 프레젠테이션(View)을 같이 구현하는 방식

• 빠르고 쉽게 개발 할 수 있다
• Controller와 View가 혼재하므로 향후 유지보수에 어려움이 겪을 수 있다

모델2
: 비즈니스 로직 영역과 프레젠테이션 영역이 분리되어 잇는 구현 방식

• 유지보수에 유리함
• 디자이너와 개발자의 분업이 가능
• BUT 설계에서 어려움을 겪을 수 있고 개발 난이도 가 높다

[실습내용]
실제로 실습해보는 과정에서 모델 1으로 하였을 때
사용자가 잘못된 정보를 계속 보내면

오늘의 발전

이런식으로 도배가되는 상황을 볼 수 있다
이런 것을 막기위해 모델 2로 JSP가 브라우저에 접근하지 못해야한다

webapp하위 폴더 web-INF에 jsp파일을 두면 서버쪽에서는 접근이 가능하다고 한다 !!!