63일차 - 페이지 보고 인터페이스 정의 & 구현

// DB의 테이블을 다 준비해놨을 것

 

3계층, 2계층... 에 대해 알아보자

 

지금 우리가 하고 있는 것

사용자가 DB 사용할 수 있게 하기

- SQL 못하는 사용자를 위해 윈도우 형태의 껍데기를 만들어주는 중 

- 콘솔 껍데기, 윈도우 껍데기, 모바일 껍데기

나이가 들면 Servlet에 대한 관심이 줄어든다?고 한다. 

 

SQL 이용하는 방법 중에, 계층 이용해서 활용하는 방법이 있다. 

 

서블릿에서 서비스 계층 하나 만들어서 - SQL 활용하는 것

컨트롤러 ---- 서비스 패키지 ---DAO-- SQL --DBMS

 

3 tier Architecture

DAO의 역할

'업무 서비스'가 나는 데이터 주는 DAO가 있으니 로그나 api나 내가 직접 다루지 않을래. 이런 느낌?

DAO, (엄무) 서비스, UI

이렇게 습관적으로 3가지로 나눠서 일을 한다고 한다.

(DAO는 2차에서 한다고 함)

- 규모 작은데 DAO 사용하면 큰 일 난다고 함

  (규모 작으면?) 서비스하고 DAO가 똑같아서는 헷갈릴거라고 ㅎㅎ 

 

DB 가지고 오는 작업을 할 때, 

데이터에는 두 종류가 있음 

1) Entity 

2) View

 

테이블과 무조건 똑같은 class를 만든다. 

entity 패키지 안에

- Comment (자바에서는 다 대명사로 하지 않고, 자바에 맞게 / 그래서 언더바도 할 필요 없고)

- 속성 Oracle에서 만든거하고 똑같게

- private 해서 속성들 넣기

  기본 생성자 / field / getter setter / toString

 

ㅡㅡㅡㅡㅡ

 

entity는 꿀벌 같은 존재

 

interface가 필요하다.

 

페이지를 보고 필요한 서비스들을 뽑아내자

1. 처음 페이지 들어오자 마자 

2. 페이지 요청

3. 검색 요청 

 

Notice에서 목록을 달라는걸 해줘야겠군 (인자 없게)

page 주면서 목록 달라고 하는 것도 준비해야겠다.

검색 요청에서는 인자 두 개 주니까 두 개 인자 주는 것도 만들어줘야겠다. 

검색하면서도 페이징 가능하면, 검색어와 함께 주는 것도 만들어야겠다.

count하는 것도 만들어야겠다.

-> 인터페이스 추가하기

new > interface

 

기본 테이블이 뭔지 봐야함

테이블을 보니 공지사항 데이터, 공지사항 데이터... 근데 작성자는! Member에 있는 녀석

-> 공지사항과 관련된 시스템 + Member는 곁다리

Member내용이 필요하니, JOIN해서 사용해야 함

 

실습을 위해서

NOTICE 라이터 아이디를 

멤버의 식별자 ID (번호)로 바꾸기

UPDATE NOTCE SET WRITER_ID ='?' WHERE WRITER_ID='?'; 

COMMIT; 

 

서비스> INTERFACE > NOTICE가 주인공인거로

 

패키지 JDBC클래스

인터페이스 추가 - NoticeService.java 

인터페이스는 public같은거 사용하는거 아님

-> 약속들만 쓰는 거임

 

이렇게 미리 정해놓는게 인터페이스.

 

내가 맡은 부분,

미리 만든 약속을 인터페이스로 만들기

 

---

(점심 후)

 

인터페이스

- 구현할 거를 미리 뽑아내는 것

 

index페이지는 따로 만들기 

- 다른 사람들이 만드는거 기다리거나 재사용하려고 하지 말고

- 공통된게 있어도 각각 만들기

 

만약 관리자가 Book을 관리하면 

관리자의 목록, 수정, 삭제 페이지가 있을텐데

- 회원이 그 Book을 조회하는 페이지가 있을텐데

 

서비스는 역할자별로 나눠지는게 아니라 

Book이라는거로! 조회, 등록, ... 

-> 한 사람이 맡아서 하기

만약 규모가 크면 역할자별로 나눠서 BookService를 만들 수도 있긴한데, 그럼 중복이 더 많아질 것

 

페이지는 

인덱스

어드민

멤버

-> 각각 만들어야

 

index페이지, 회원 페이지, 관리자 페이지.... 

그런 페이지들을 서비스하기 위한게 책이면 책 서비스. 회원이면 회원 서비스. 

특정 역할자 뿐만 아니라 다른 역할자에서도 보이는거면 같은 BookService로 제공해주기

 

그 페이지를 만들기 위한! 인터페이스를 만들어야. 

/study url로 들어가면 스터디에 관한 것들의 정보가 있음 (등록, 수정, 삭제,...)

-> studyService로

 

/index url 은 스터디에 관한 것도 있고, 시험에 관한 것도 있고, ~에 관한 것도 있고~ 

-> 이건 다른 서비스들이 만들어질 때까지 기다려야 할까? 

    아니다. 

    이건 따로! 

 

 헷갈렸던점

Q. 데이터들 가지고 오는게 book, rating, review, gathering.... 마치 index 페이지들 같은데?? 

    따로 인터페이스 만들어줘야 하는거 아닌가.   

-> A. 아니다. 

        별점 보면 '아 이건 별점 테이블에서 가지고 왔겠구나'라는게 보이는게 아니라 '도서 관련 정보구나'라고 생각하는게 정상적일 것 (이 페이지에서)

-> 따로 인터페이스 만드는게 아니라 따로 따로 다 가지고 오는게 맞다. 

 

그리고 피드백 받은 거 -> URL 고치기 ! 

Adimin > Book > Detail 이렇게 

 

// 

 

오라클에 db 넣어서 

jdbc 연결해서 잘 나오는지 확인하기! 

 

 

---

인터페이스!를 정의한다. 

약속(인터페이스)을 구현 ----- 약속을 정의 (정의하는 쪽은 제품 쪽!)  https://ubermensch-with.tistory.com/189?category=919210

 

약속된 것들을 구현해준다.