2022.02.17의 기록

▶ 오늘 실현 가능한 세부 목표

 

=>  공부 관련

1) 금일 배운 내용 복습 

2) CS 지식 개발 상식 코너

3) 자바의 정석 12장 제너릭스(Generics)

4) MVC 적용 시켜 자바 프로그램

 

 

=>  파이널 프로젝트 관련

1) 안건 회의 요소 생각

2) 구글 크롬 디버깅 공부

 

---

▶ 수업 공부 관련

MVC Design Pattern

클라이어트 요청에 대한 모델 클래스 매핑 설계

• ⇒ 모든 모델 클래스는 같은 인터페이스를 상속 받아 동일한 구조로 작성 - 사용성 및 유지보수 효율성 증가

모든 모델 클래스가 반드시 상속 받아야 하는 인터페이스

• ⇒ 모델 클래스의 요청 처리 메소드 작성 규칙 제공
• ⇒ 요청 처리 메소드 호출 편의성과 유지보수의 효율성 증가
• 요청 처리 메소드는 request , response 인스턴스를 매개변수로 전달받아 요청에 대한 처리를 실행하고 뷰 관련 정보(이동 관련 정보)를 반환하도록 작성

뷰(view) 관련 정보를 저장하기 위한 클래스

• 리다리엑트 이동 : 클라이언트에게 URL 주소를 전달하여 다시 요청하도록 응답 처리
• ⇒ 클라이언트 브라우저의 URL 주소 변경
• 포워드 이동 : 현재 웹프로그램(Controller)에서 다른 웹프로그램(JSP)으로 스레드를 이동하여 응답 처리
• ⇒ 클라이언트 브라우저의 URL 주소 미변경

모델 클래스가 상속받은 인터페이스를 이용하여 참조변수 생성

• 참조 변수에는 인터페이스를 상속받은 모든 자식클래스의 인스턴스 저장 가능
• 부모 인터페이스의 추상메소드를 호출하면 참조변수에 저장된 자식 인스턴스(모델)의 오버라이드 메소드 호출 - 메소드 오버라이드에 의한 다형성
• => 요청 처리 메소드를 호출하여 뷰 관련 정보를 반환받아 저장

반환받은 뷰 관련 정보를 이용하여 클라이언트에게 응답 처리

• 컨트롤러(Servlet)에서 뷰(JSP)로 스레드를 이동하여 JSP 문서로 클라이언트에게 처리 결과(HTML)를 전달하여 응답

Model

⇒ 요청에 대한 처리는 Model이 한다.

• Model 클래스의 요청 처리 메서드는 Service 클래스의 메소드를 호출하여 요청 처리
• Request Scope : 스레드가 이동된 JSP 문서에서만 속성값으로 저장된 인스턴스를 반환받아 사용
• requset, response 객체는 다 Controller가 제공
• Model2에서는 session보다 request 객체를 더 많이 사용함
• 예외처리를 통해서 서버의 잘못된 코드를 잡아내서 클라이언트에게는 만들어진 에러페이지로 응답 됨.

보안 설정할 때 필요한 것이 AOP (나중에 스프링 때)

VIEW

• 절대 처리하지 않음
• 제공된 값을 가져와 이용하는 것.

 

⇒ Model 2 방식 - MVC Design Pattern

Business layout - Model & Service

persistent layout - MyBatis 프레임워크 (DAO, DB)

presentation layout - View

Controller

• 가독성 문제를 해결해야 함
• 인스턴스도 미리 생성해 놓는 방식
• 첫번째 방식 : 자료구조 컬렉션을 사용하면 속도가 빠름
• 웹 프로그램에서 필드의 초기값은 init()가 부여
• ⇒ 클라이언트 요청에 의해 서블릿 클래스가 인스턴스로 생성된 후 가장 먼저 자동 호출되는 메소드 인스턴스 생성 후 한번만 호출 - 초기화 작업 (ServletConfig 매개변수로 WAS의 정보를 가지고 초기화 가능하기 때문에 생성자 대신 사용)
• 컨트롤러 서블릿 객체도 요청하기 전 미리 만들어두면 더 빠르게 동작하지 않을까? (본래는 요청을 받아야 실행되서 객체가 만들어지지만)
• <load-on-startup> : WAS 실행 시 서블릿 클래스를 인스턴스로 생성하는 엘리먼트
• ⇒ 클라이언트가 요청하지 않아도 서블릿 클래스를 인스턴스로 생성 - init() 메서드
• ⇒ 엘리먼트 값은 0 이상의 정수로 설정하며 값이 적을 수록 먼저 인스턴스로 생성
• 두번째 방식 : Properties 파일에 요청정보와 모델 클래스를 저장하고 파일의 내용을 읽어 Map 인스턴스의 엔트리로 추가하여 저장 - 유지보수의 효율성 증가
• ⇒ Properties 파일 : 프로그램 실행에 필요한 값을 제공하는 텍스트 파일
• ⇒ WEB-INF 폴더에 만듬 → 클라이언트가 접근하지 못하게 (나중에는 JSP 문서들도 여기다가 옮길거임. 요청하지 못하게)
• 세번째 방식 : Properties 파일의 정보가 바뀌면 또 바꿔줘야 하나? 당연 XML 엘리먼트 이용
• ServletConfig.getInitParameter(String name) : web.xml 파일의 servlet 엘리먼트로 제공되는 값을 반환하는 메서드 → init-param 엘리먼트로 이름과 값을 설정하여 제공
• <init-param> : 웹프로그램(서블릿)에게 값을 제공하기 위한 엘리먼트
• 이런식으로 하면 property 파일이 바뀌더라도 web.xml에서 이름만 바꿔주면 됨. - 유지보수의 효율성 증가
• 모델 클래스를 이용하여 모델 인스턴스 생성 - 리플렉션 기능 이용
• 리플렉션 : 프로그램 실행 시 클래스(Clazz)를 읽어 인스턴스 생성하여 인스턴스의 요소 (필드 또는 메소드)에 접근 가능하도록 제공하는 기능 → 접근 지정자의 구애를 받지 않고 객체를 생성할 수 있다.

---

▶ 개인 공부 관련 1

1. MVC 패턴을 적용시키는데 DB를 사용하지 않을 것이다. 

문제 : DB가 필요없으면 VO도 필요없고 액션을 취해주는 놈을 Model로 하는게 맞는가?

과정 : 현재까지 배운 과정으로는 입력 값 검증 및 액션은 Model로 하는게 낫겠다. 

 

---

▶ 개인 공부 관련 2

• 제너릭스(Generics)

  • 다양한 타입의 객체들을 다루는 메서드나 컬렉션 클래스에 컴파일 시의 타입체크를 해주는 기능이다.
  • 객체의 타입을 컴파일 시에 체크하기 때문에 객체의 타입 안정성을 높이고 형변환의 번거로움이 줄어든다.
  • 타입 안정성을 높인다는 것은 의도하지 않은 타입의 객체가 저장되는 것을 막고, 저장된 객체를 꺼내올 때 원래의 타입과 다른 타입으로 잘못 형변호나되어 발생할 수 있는 오류를 줄여준다는 뜻.
  제너릭스의 제한
  • static 멤버에 타입변수 사용 불가능. 인스턴스 변수로 간주되기 때문이다.
  • 제너릭 타입의 배열을 생성하는 것도 허용되지 않음. ⇒ new 연산자는 컴파일 시점에 타입이 뭔지 정확히 알아야 하기 떄문
  • ⇒ 필요할 경우 Reflection API의 newInstance()와 같이 동적으로 객체를 생성하는 메서드로 배열을 생성하거나, Object 배열을 생성해서 복사한 다음 T[]로 형변환 하는 방법 등을 사용.
  와일드 카드
  • 제너릭 타입이 다른 것만으로는 오버로딩이 성립하지 않음.
  제너릭 타입의 형변환
  • 제너릭 타입과 원시 타입간의 형변환은 가능하다
  • 제너릭 타입과 넌제너릭 타입간의 형변환은 항상 가능하지만 경고가 발생한다.
  • 낮은 타입으로의 형변환은 불가능하지만, 와일드 카드가 포함된 제너릭 타입으로 형변환은 가능하다. (확인되지 않은 타입은 경고 발생)
  • ⇒ 확정된 타입이 아니므로 컴파일러는 미확정 타입으로 형변환하는 것이라고 경고내림.
  제너릭 타입의 제거
  • 제너릭 타입에서는 원시 타입을 사용하지 말자.
  • 제너릭 타입의 경계를 제거한다 ( bound)
  • 제너릭 타입을 제거한 후에 타입이 일치하지 않으면, 형변환을 추가한다.

---

▶ 파이널 프로젝트 관련

1. 커뮤니티, 쇼핑몰, 중계 플랫폼 

=> 이 3개는 무리라고 하심.. 

=> 한 개를 뭘 뺄지 상의를 해보자

> 커뮤니티를 제외하기로 결정

2. 사용할 기술 스택과 협업 관리 도구 확실시

> 배운 기술 사용 예정

> 오라클

> Git (bash 생각중.) 

> 스프링이 괜찮으면 boot도 생각중이나 안 될 가능성이 크다.

3. 역할 분담

=> 페이지 별

=> Front & Back 2:2?

> 내일까지 정하기

> 실력보다 흥미가 가는 분야로의 선택