pom.xml 파일에 프로젝트의 버전 변경 >> maven 프로젝트 업데이트 >> 한글 인코딩 작업 실행
이제 파일 업로드, 다운로드에 필요한 라이브러리를 추가할 것임
commons fileupload 라이브러리 추가할 것 >> 1.3.3 버전 >> pom.xml 에 추가
입, 출력을 담당하는 라이브러리 >> 2.4 버전 >> pom.xml 에 추가
class 파일로 bean 객체를 추가
기존에 servlet-context.xml 에서 빈 객체를 등록하던 방식을 클래스 파일에서 어노테이션을 사용해서 등록하여 사용
( 위 xml 파일은 어노테이션을 활용해서 작성하는 방법을 설명하기 위해 작성했으므로 xml 파일 내 빈 객체 등록 부분은 주석처리 하였음 )
파일 업로드 경로 작성 >> uploadForm.jsp 에 업로드 폼 작성 >> 파일 전송 시 이동될 경로 작성
Controller 에도 파일 받아서 처리할 url 경로 작성 및 넘어온 파일을 변수로 담아서 출력해봤음 >> service 쪽으로 받은 파일을 넘겨줌
파일 저장 로직 완성 ( 파일 명 앞에 저장 시간을 년월일시분초 형식으로 붙인 뒤 변수로 저장 경로를 지정하여 저장 )
DB 에 저장한 이미지의 이름을 저장해볼 것임
create table file_image(
id varchar(20) primary key,
name varchar(20),
img_name varchar(100)
);
sql 문 작성 및 실행
▼ DB 연동 작업 ▼
DB 연동에 필요한 라이브러리 추가
root-context.xml 작성
fileMapper.xml 세팅
▲ DB 연동 세팅 완료 ▲
DB 와 연동할 객체 DTO 작성
파일을 저장하지 않으면 DB 에 nan 으로 처리, 파일을 저장한다면 파일 명을 DB 에 저장
FileMapper 인터페이스에 메소드 추가
FileMapper.xml 파일에 sql 문 작성
FileMapper.xml 파일에 namespace 를 설정해주지 않아서 다시 고침
이미지 파일 전송해보니 정상적으로 파일 이름 DB 에 저장되는 모습
파일 저장도 되는 모습
( 현재 테이블에 id 값을 primary key 로 지정해놓아서 동일한 아이디로 파일 업로드를 하면 무결성 조건 에러가 발생되는데 이때, 정상적으로 파일은 디렉토리에 저장되지만 DB 에 파일명을 저장할때 무결성 조건 에러를 만나면서 DB 에 파일명이 저장되지는 않는다,,,, )
파일을 jsp 파일에 출력해볼 것임
경로 생성
Controller 에서 model 객체를 Service 에 전달, Service 에서는 Mapper 를 사용해 데이터를 가져와서 model 에 저장할 것임
FileMapper.xml 에 select 문 작성 ( resultMap 을 사용해서 컬럼명과 변수를 Mapping )
전달받은 데이터를 forEach 문으로 화면에 출력
다운로드와 이미지 출력 구현
download 경로를 컨트롤러에 작성 및 download 기능을 구현
파일 삭제 기능 추가
result.jsp 에 파일 별로 a 삭제할 경로와 파일 출력할 img 태그 추가
delete 경로로 들어왔을때 file 명과 id 값을 받아서 service 로 전달
service 에서는 mapper 로 id 값을 전달하여 db 에 저장된 파일정보를 삭제, 디렉토리 내의 파일은 service 에서 삭제
체크박스 클릭 후 로그인 시 : on, 체크박스 클릭하지 않고 로그인 시 : null ( required = false 처리를 해줘야 함 ) 처리 후 체크된 상태로 로그인 성공 시 cookie 값을 발급하고 유저의 id 정보를 쿠키 값으로 저장시킨다
alter table membership add
session_id varchar2(100) default 'nan' not null;
테이블 추가
( 값이 존재하지 않는다면 nan 으로 저장된다 )
테이블 추가 완료
DB 에 추가된 컬럼을 관리할 sessionId 변수와 getter / setter 를 DTO 에 추가 >> 이후 Mapper.xml 에도 session_id 컬럼과 sessionId 변수를 mapping 시켜준다
사용자의 쿠키 값과 DB 에 저장된 값이 일치해야 자동 로그인을 처리할 것임
Service 인터페이스에 메소드 추가 >> ServiceImpl 에서는 id 값과 autoLogin 값을 HashMap 에 키와 값으로 저장하여 mapper 에 전달
Mapper 인터페이스에 메소드 추상화, Mapper.xml 에 해당 메소드에 매핑될 sql 문 작성
자동 로그인 체크 후 로그인 성공 시 DB 에 저장되는 것 확인
AutoLogin Interceptor 에서 loginCookie 값이 있는지 확인 후 해당 값이 있으면 DB 안에 설정되어 있는 session_id 의 값이 "on" 인지 체크한 뒤 session 의 LOGIN 키의 값을 id 로 생성해준다 >> servlet-context.xml 에 index 경로로 들어오기 전 실행될 AutoLogin 클래스 Interceptor 선언
servlet-context.xml 파일에서 모든 경로에서 autoLogin 으로 설정한 Interceptor 가 작동하게 설정
Controller 에서 logout 경로로 들어올 시 cookie 값을 만료시키고 DB 안에 on 으로 저장되어 있던 session_id 컬럼의 값을 nan 으로 변경시킨뒤 세션을 모두 삭제하고 login 페이지로 돌려보낸다
Interceptor : 컨트롤러로 가기 전에 무언가 처리할 내용 ( preHandle ) 이나, 컨트롤러 까지 로직 작동 후 클라이언트에게 도착하기 전에 처리할 내용 ( postHandle ) 을 담당 ( 불필요한 리소스를 차단 )
Interceptor 패키지, 클래스 파일 생성
메소드 오버라이딩
servlet-context.xml 파일에 MemberInterceptor 클래스를 /index 경로가 실행될때 사용할 Interceptor 로 설정 ( /index 경로로 접속할때 컨트롤러로 전달되기 전 오버라이딩 한 메소드인 preHandle 이 실행, 컨트롤러로 전달된 후 오버라이딩 한 메소드인 postHandle 이 실행된다 )
MemberInfo 를 로그인한 사용자만 확인할 수 있게 Interceptor 를 사용해서 설정할 것임 >> Controller 에서도 세션을 기준으로 redirect 로 처리할 수 있음 그러나 로직을 세션을 비교하는 부분마다 다 작성해줘야 하기 때문에 비효율적....
servlet-context.xml 에 Interceptor 로 미리 로직을 분류할 경로를 추가 >> session 값을 미리 Controller 에 도착하기 전에 Interceptor 에서 확인하여 Controller 로 이동시킬지 Controller 로 이동시키지 않고 redirect 로 login 페이지로 이동시킨다
사용 이유 : 싱글톤 패턴은 전체 애플리케이션에서 단 하나의 인스턴스만을 생성하여 사용하고자 할 때 사용한다
이는 공유 리소스 관리나 크로스-커팅 서비스( 애플리케이션의 여러 부분에 걸쳐 공통적으로 적용되는 기능을 말한다 ) 제공에 유용하다
스프링에서는 기본적으로 모든 빈객체를 싱글톤으로 생성하여 관리한다
싱글톤 사용의 장점
1. 메모리 낭비 방지
2. 전역 인스턴스로 애플리케이션 어디서나 접근이 가능
3. 데이터 공유의 용이성
싱글톤 사용의 단점
1. 싱글톤 인스턴스가 너무 많은 역할을 담당하게 되면 변경과 테스트가 어려워진다
2. 멀티스레드 환경에서 동기화 처리가 필요하다 ( 생성된 빈 객체를 동시에 사용할 수 없기 때문 )
팩토리 메소드 패턴 ( Factory Method Pattern )
사용 이유 : 객체 생성 처리를 서브 클래스로 분리하여 객체 생성 로직의 변경이나 확장이 필요할 때 유연하게 대처하기 위해 사용
스프링에서 인스턴스 생성을 추상화하고, 이를 상속받는 서브 클래스에서 해당 인스턴스의 구체적인 타입을 결정하게 하게 한다
public interface PaymentProcessor {
void processPayment();
}
public class CreditCardProcessor implements PaymentProcessor {
@Override
public void processPayment() {
// 신용카드 결제 로직 처리
}
}
public class PayPalProcessor implements PaymentProcessor {
@Override
public void processPayment() {
// PayPal 결제 로직 처리
}
}
@Component
public class PaymentProcessorFactoryImpl implements PaymentProcessorFactory {
@Override
public PaymentProcessor createPaymentProcessor() {
// 설정 등에 따라 생성할 프로세서 결정 로직
return new CreditCardProcessor();
}
}
코드 예시로서 결제에 관련된 인터페이스를 생성한 뒤 해당 인터페이스를 상속받아 기능에 따라 다양하게 구현
팩토리 메소드 패턴 사용의 장점
1. 유연성 : 팩토리 메소드 패턴은 프로그램 실행 중에 어떤 객체를 생성할지 결정할 수 있게 해준다, 이는 프로그램이 더 유연하게 동작하도록 돕는다
2. 낮은 결합도 : 클라이언트 코드가 구체적인 클래스를 몰라도 되기 때문에 서로 간의 의존성이 낮아진다
3. 유지보수의 용이성 : 팩토리 메소드 패턴을 사용하면 새로운 객체 타입을 추가하거나 변경해도 기존 코드를 수정할 필요가 없어 유지보수가 쉬워진다
팩토리 메소드 패턴 사용의 단점
1. 복잡성 증가 : 팩토리 메소드 패턴을 사용하면 각 객체마다 팩토리 클래스가 필요하기 때문에 코드가 복잡해질 수 있다
2. 서브 클래스 증가 : 새로운 객체 타입을 추가할때마다 새로운 서브 클래스를 만들어야 하기 때문에 클래스의 갯수가 증가하며 프로젝트의 크기와 복잡성을 증가시킬 수 있다 ( 서브 클래스의 증가는 관리해야 할 코드의 양의 증가와 테스트와 디버깅을 더 복잡하게 만들 수 있다 )
프록시 패턴 ( Proxy Pattern )
사용 이유 : 원본 객체에 대한 접근을 제어하거나, 원본 객체의 생명주기를 관리하거나, 원본 객체의 작업을 가상화하기 위해 사용
// 파일 인터페이스
public interface File {
byte[] load();
}
// 실제 파일을 로드하는 클래스
public class RealFile implements File {
private String path;
public RealFile(String path) {
this.path = path;
loadFromDisk(path);
}
private void loadFromDisk(String path) {
System.out.println("디스크에서 파일 로드: " + path);
}
@Override
public byte[] load() {
System.out.println("파일 내용을 반환합니다.");
return new byte[0]; // 실제 파일 내용을 반환
}
}
// RealFile 객체의 생성을 지연시키는 프록시 클래스
public class ProxyFile implements File {
private RealFile realFile;
private String path;
public ProxyFile(String path) {
this.path = path;
}
@Override
public byte[] load() {
if (realFile == null) {
realFile = new RealFile(path);
}
return realFile.load();
}
}
// 클라이언트 코드
public class ProxyExample {
public static void main(String[] args) {
File file = new ProxyFile("test_file.txt");
// 파일이 실제로 필요할 때만 로드됩니다.
file.load();
}
}
예시 코드 ( ProxyFile 클래스에서는 요청한 파일의 객체가 이미 생성된 상태라면 다시 파일을 불러와서 객체를 생성하는 과정을 거치지 않고 이미 생성되어 있는 객체를 재사용한다 )
Member 클래스 생성 ( Entity 어노테이션으로 해당 클래스를 DataBase 역할을 하는 빈 객체로 등록 후 id, name 변수 선언 및 getter / setter 선언 ), Id 어노테이션을 사용해서 id 값이 primary key 임을 선언
DB 안에 데이터 빈 것 확인 >> jpa 를 사용하여 DB 에 데이터 저장 >> 데이터 저장된 것 확인
try catch finally 를 사용하여 예외 처리 및 자원 관리를 진행
위와 같이 insert 문을 다시 실행시켜 id : 2 , name : HelloB 데이터를 입력하려고 하니 기존에 DB 에 있던 id : 1, name : HelloA 데이터가 삭제되고 새로 넣은 데이터만 나오는 것을 확인
persistence.xml 에서 hibernate 옵션 중 hbm2ddl.auto 의 값이 create 로 설정되어 있는데 이 설정은 애플리케이션을 재시작할 때마다 데이터베이스를 새로 생성하기 때문에 기존 데이터가 삭제되므로 해당 값을 update 로 변경해주거나 주석처리한다 ( 나는 주석처리 후 진행 ) >> 이후 다시 명령문 실행 후 확인
( 배포 환경에서는 이 속성 자체를 사용하지 않는 편이 좋다 )
entityManager 의 find 메소드를 사용하여 id 값이 1인 데이터를 찾아온 뒤 출력 >> 찾아온 데이터의 name 값을 HelloJPA 로 변경 >> 변경된 것 확인
@Transactional = insert, delete 와 같은 쿼리문을 테스트한 뒤 다시 롤백하여 처음 상태로 돌려주는 어노테이션
memberMapper.xml 에 select 문 작성 ( 현재 가져올 컬럼 중 primary key 가 없기 때문에 모두 result 태그를 사용, 만약 가져오는 컬럼 중 primary 키가 있는 컬럼은 result 가 아닌 id 태그로 매핑해줘야 한다 )
result : primary key 가 아닌 컬럼 mapping
id : primary key 인 컬럼 mapping
DAO 에 select 문을 실행시킬 list 메소드 작성
TestMember.java 에서 단위 테스트 진행 ( DAO 만 실행 테스트 ) >> null 이 아니면 초록색 바
MemberService 인터페이스 작성 ( jsp 쪽으로 데이터 전달해 줄 것이므로 model 객체를 전송 ) >> MemberServiceImpl 에서는 해당 model 객체를 받아서 model 객체 안에 list 라는 이름으로 DAO 의 list 메소드가 반환한 값을 addAttribute 로 추가해준다
Controller 에서 Service 의 list 메소드 호출할때 model 객체 넘기는 코드 작성
통합 테스트 진행 >> 성공
index.jsp 작성 후 테스트 >> list 객체 잘 들어오며 사이즈와 데이터 값도 잘 출력되는 것 확인
기존 insert 경로는 데이터 추가 후 바로 jsp 파일을 출력해서 list 가 존재하지 않아 출력되지 않았는데 이를 출력해주기 위해 redirect 를 사용해서 클라이언트가 다시 요청해서 데이터를 받게끔 설정 >> 이렇게 리다이렉트를 설정해주면 통합 테스트에서 리다이렉트가 정상적으로 진행되는지를 따로 설정해주지 않으면 오류가 발생되므로 코드를 변경해준다
메이븐 프로젝트 업데이트 ( 단축키 Alt + F5 ) >> JRE System Library 에 JavaSE 버전이 1.8 로 변경된 것 확인
※ 꼭 업데이트는 pom.xml 변경 후 저장한뒤 할 것 ※
HikariCP 라이브러리 추가
Spring JDBC 아무 버전이나 라이브러리 추가 >> 상단에 내가 사용중인 스프링 버전의 변수를 복사 >> 내 스프링 버전으로 변경
Oracle DB 버전 확인 후 라이브러리 추가 ( Oracle DB 버전이 11 버전 : ojdbc6 설치, Oracle DB 버전이 19 버전 이상 : ojdbc8 에 맞는 버전으로 설치 ) >> 나는 Oracle DB 버전이 19.3.0.0 버전이므로 ojdbc8 의 19.3.0.0 버전 라이브러리를 추가
MyBatis 버전 3.4.6 라이브러리 추가
MyBatis 와 Spring 을 연동시켜주는 MyBatis Spring 을 버전 1.3.2 로 설치
Controller 에 사용자가 아이디, 비밀번호 입력 시 이동될 user_check url 작성
MemberService 인터페이스에 user_check 메소드 선언 >> MemberServiceImpl 에서는 MemberMapper 를 통해 id 값에 해당하는 DB 저장 값을 가져와 DTO 에 저장하고 해당 값으로 입력된 비밀번호와 일치하면 0을 리턴, 아니면 1을 리턴한다
MemberMapper 인터페이스에 user_check 메소드를 추상화 >> MemberMapper.xml 에서 select 문을 작성 ( id : 메소드명, resultMap : 결과를 위에서 선언한 MemberDTO 형태로 매핑하여 가져오겠다는 뜻 )
session 의 값들을 처리할 인터페이스 생성 >> Controller 에서는 session 을 처리할 인터페이스인 MemberSessionName 을 상속받은 뒤 사용 >> successLogin.jsp 에서는 세션 값인 loginUser 를 출력 >> 결과
