일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |
- Windows10
- 윈도우10 vpn
- 성수족발
- 노리로또
- 타카마루
- 분기날짜
- 랍스터 찜
- 신주쿠맛집
- 핸드폰 찾기
- cisco vpn
- 크롬 인너넷연결 안됨
- 로니세라
- 10 올림
- 강화 프로방스
- 코로나백신 갈증
- 화이자백신
- 코로나백신 부작용
- 신주쿠 로컬식당
- 응용 프로그램 내 구입
- 크롬 인터넷연결
- 코로나백신이상증상
- 코로나백신
- 안드로이드폰 위치
- 크롬 타임아웃
- 10원단위 올림
- windows10 cisco vpn
- takanaru
- windows10 크롬
- 코로나백신 어지러움
- 오라클
- Today
- Total
이거 맘대로 되는 세상이 아니구만...
자바빈?? 본문
1) 위의형태를 가진 모듈화를 모델 2라고 한다
참고로 자바 빈의 3종류를 적어보면...
- 액션 빈즈 : insert, delete, create등 직접적인 행위를 할 수 있도록 만들어진 정형화 된 클래스로, 웹페이지에서는 서블릿이
대신한다. (확실하게 임무 분담을 정해놓을 일이지 이 넘이해도되고 저 넘이 해도 되는 불분명함이란...)
- 데이타 빈즈 : 구조체 형식의 클래스로서 자료를 가지고 있으며,setter메소드와 getter 메소드로 형성되어 쉽게 사용할 수 있다.
이는 JSP 빈즈 활용에 가장 널리 사용되고 있다.
- Visible 빈즈 : AWT의 Button 컴포넌트, List 컴포넌트와 같은 클래스로 JSP에서는 활용도가 별로없어 사용되지 않고있다.
2) 모델 1 은 브라우저 <-> View(Jsp Page) <-> 모델(자바빈) <-> DB 형태이다.
그리기 귀찮으므로 패스...
하지만 보통 어깨너머로 배운 사람들이검색과 책 독학으로 보통 구현하는 형태는
3) 웹브라우저 <-> JSP(View) <-> DB의 형태이다
이것은 모델링이라고 불리지 아니하는 듯하다. 본좌는 맨위의 것을 모델3, 두번째 것을 모델2로 잘못 알고 있었던
듯하나, 지금까지 책과 검색등으로 알아낸 바로는 맨위가 모델2, 두번째가 모델1, 마지막 JSP 혼자다하는 것은
아무것도 아닌것인 듯하다...
현재까지 이해된 부분으로서 MVC 역할 분담에 따른 장점의 중론을 도출하자면, 일반적으로
DB접속 컨넥션객체라던가...(이것은 동적페이지에 수시로 쓰일 것이다...) 전체 사이트 구현에 있어
중복되는 연산, DB입력등의 소스를 따로 구분하여 만들어 필요할 때 마다 불러다 쓰는것...
책에서 인용하자면 표준화 된 모듈을 특정형태의 레고블럭 처럼 끼워 맞추어 쓰기만 하면 되는 것으로,
개발자들은 뭐.. 회사에 가면 각각에 쓰는 모듈이 있겠지만.. 자신이 개발한 모듈이라면 언제든지 백업해서
이직할 때 가지고 다닐 수 도 있고, 웹 에이전시에서 일해도 마찬가지 일 듯하다.
뭐 Php같은 것에서도 모델화라는 것이 따로 있는 것 같지 않지만, Php안에서 컨트롤하는 Php를 인클루드
함으로써 쓰는 방법을 쓴 기억이 있다.
검색에서 혹자의 말을 인용하자면
일단 MVC가 무엇인지는 아시죠? JSP를 MVC 모델로 적용시켜보자면
Model 은 정보를 담고있는 객체, 자바빈즈를 뜻합니다.
View 는 정보를 표현하는 객체, JSP(Java Server Page)를 뜻합니다.
Controller 는 정보를 컨트롤하고 Model과 View 사이를 중재하는 객체로, 이것을
JSP에서는 서블릿이라고 합니다.
이렇게 데이터-표현-정보처리(로직)을 구분하는 것은 재사용성과 가독성(읽기쉽게)을
높히기 위함입니다. 기존 스크립트 언어들은 이런면에서 페이지(View) 안에서 모든
정보를 표현하고(Model) 처리됨으로써(Control) 재사용이 힘들고, 읽기도 힘들었죠.
그런면에서 질문하신 모델을 살펴보죠.
모델 1은, 정보는 자바빈즈에 담고, 표현은 JSP로 합니다.
그럼 로직은? 자바빈즈 내부에 담기거나 JSP에서 처리가 되겠지요. 어쨌든 이렇게
표현할 데이터와 표현방식을 구분함으로써 데이터-표현을 자유롭게 바꿀 수 있습니다.
한 JSP가 여러 자바빈즈를 표현한다던가, 한 자바빈즈에서 여러가지의 JSP를 쓸 수 있다
던가... 그럼 속도는? 물론 객체지향 설계는 속도를 떨어뜨립니다만, 무시할 수 있는 수준
입니다. 물론 님이 질문하신 것처럼 '보기가 드러워서' (가독성이 떨어진다고 하죠) 라는
것도 이유가 됩니다. 가독성이라는 것은 코드에 있어서 절대 무시할 수 없는 겁니다.
모델 2가 제대로된 JSP 구현이라고 할 수 있겠네요.
데이터는 자바빈즈가, 데이터처리는 서블릿이, 표현은 JSP가 함으로써 비즈니스 로직과
데이터, 표현을 완전히 분리해서 처리하는 겁니다. 이렇게 분리하면 데이터나 비즈니스
로직만을 부분적으로 바꿔도 전체에는 영향이 없을 뿐만아니라 다양하게 확장할 수 있
는 가능성을 열어두게 됩니다. 물론 가장 중요한 유지보수 문제도 쉬워지지요.
즉, 모델 1은 컨트롤러가 모델이나 뷰에 포함된 MV 형태를 띄고있고, 모델 2는 완전한
MVC 형태를 적용하고 있다고 볼 수 있겠네요. 바람직한 형태는 모델 2입니다.
그리고 서블릿을 모르면 컴포넌트를 못 만든다고 한 것은... 원래 프로그램에서 가장
중요한게 비즈니스 로직, 즉 데이터를 어떻게 처리하느냐-라는 컨트롤러의 역할입니다.
JSP에서는 서블릿이 이 역할을 담당하도록 설계되었는데 이걸 쓰지못한다는 말은
비즈니스 로직을 따로 구분할 수 없다는 말이고, 그렇다는 건 완전한 JSP의 모델을
만들수 없을 뿐만아니라 재사용도 제한적이라는 말이되겠죠.
컴포넌트는, 부품으로서 완벽한 하나의 객체를 말합니다. 그러니까 재사용 가능한
객체를 말하는거죠. 여기서도 활용가능하고 저기서도 활용가능하고... 이제 이해가
가시나요? 서블릿이 없이 제작된 JSP 로직은 따로 구분이 안되어 있어서 그것만 떼어
낼수가 없기 때문에 부품'으로서의 의미가 없습니다. 그래서 컴포넌트가 못 되는거지요.