[Java] 게시판 제작(14)

[게시판 제작 ~ing]

• 작성된 모든 코드는 저의 깃허브 리포지터리에서 확인하실 수 있습니다.
• 리포지터리 주소 URL : https://github.com/psm817/full_stack_proj_2024_03

GitHub - psm817/full_stack_proj_2024_03

 

[MVC 패턴]

• MVC 패턴이란 Model-View-Controller 의 약어로 주로 GUI 기반의 애플리케이션 개발에 사용된 디자인 패턴이다.
• 개발 초창기에 한 파일에 모든 코드를 넣었기 때문에 기능을 수정하거나 특정 코드를 찾을 때 불편함이 컸다.
• 위와 같은 불편함을 해결하고자 만들어진 것이 MVC 패턴이다.
• 화면과 데이터 처리를 분리하여 코드 간 종속성을 줄이고 구성 요소 간의 역할을 명확하게 함으로써 코드 분리가 쉽고 협업을 용이하게 하는 장점을 가지고있다.

 

[Model]

• MVC 패턴 중 Model은 데이터를 처리하는 영역이다.
• 현재 구현된 게시판에는 DB가 아직 존재하지 않지만, 실제 프로젝트에서는 DB와 연동하는 Dao(Data Access Object)와 데이터 구조를 표현하는 Do(Data Object)로 구성된다.
• 쉽게 말해서 현재 구현된 게시판에서는 Dao.java / ArticleDao.java / MemberDao.java 클래스가 해당 역할을 함으로써 DB를 관리하는 대신 articles와 members와 같은 리스트 배열을 DB로 가정하고 관리하고 있다.
• 한마디로 Dao는 음식점에서 대표하는 메뉴를 요리하는 요리사와 같은 역할을 한다.

 

[View]

• MVC 패턴 중 View는 사용자에게 보이는 화면이다.
• 현재 구현된 게시판은 Console로만 해당 기능이 구현되어 있고 따로 지정된 화면은 아직 없다.
• 흔히 UI라고도 부르는 View 단은 Controller로 부터 전달된 데이터의 출력과 HTML, CSS 등을 통해 화면의 디자인을 처리하는 영역이라고 생각하면 좋다.
• 한마디로 View는 음식점에서 대표하는 메뉴를 보기좋게 플레이팅을 한 접시와 같은 역할을 한다.

 

[Controller]

• MVC 패턴 중 핵심인 Controller는 모든 사용자의 요청에 중심에 위치한다.
• 다시 말해 사용자가 어떠한 작업을 수행시에 특정 View로 요청이 가는 것이 아니라, Controller에서 우선적으로 요청을 받아들인다.
• Controller는 특정 View를 지정해야 하기 때문에 View와 종속관계가 발생할 수밖에 없는 구조이다.
• 따라서 프로그램의 규모가 커질수록 Controller의 역할이 상당히 커지기 때문에 복잡해지고 관리가 어려워 진다.
• 한마디로 Controller는 음식점에서 주문을 담당하는 점원과 같은 역할을 한다.

 

[회원, 게시물 서비스 도입]

• 현재까지 구현된 게시판 프로그램도 앞으로 유지보수가 더욱 용이하도록 서비스라는 패키지와 클래스를 추가해야 한다.
• 다음 작업은 코드를 직접 보여드리기에 양이 상당하여 실제 코드는 글 상단의 리포지터리 주소를 통해 참고 부탁드립니다.
• 각 회원과 게시물의 서비스 역할은 명령어 요청을 받은 Controller에서 바로 Dao로 연결되지 않고, ArticleService, MemberService를 거쳐 핵심 로직들이 종속성있게 실행될 수 있도록 한다.

 

1. 게시물 관련 로직

• Main 클래스부터 프로그램이 진행되는 순서는 다음과 같다.
• 프로그램의 진행 순서는 무조건 단방향이며, 절대 역순으로 실행될 수 없다.
• Main -> App -> Controller -> ArticleController -> Container -> ArticleService -> Dao -> ArticleDao 의 순서이다.
• Main에서 시작해서 App에서 각 Controller로 요청 및 라우팅, 요청응대, 실제 기능 수행, DB 관리의 순서라고 생각하면 좋다.
• 리포지터리를 통해 추가 및 수정된 코드를 보면, 핵심 기능 역할을 하는 메서드는 그대로 유지되고, 프로그램의 진행순서를 맞춰 전체적인 구조가 수정되었다.
• 앞으로는 무조건 Controller에서 명령어의 요청을 받고, ArticleController에서는 ArticleService를 거치지 않고 절대 ArticleDao로 연결될 수 없다.
• 다시 말해 ArticleController.java 클래스에서 Dao라고 써있는 변수나 메서드가 없어야 정상인 것이다.

 

• 다음은 추가된 ArticleService.java 클래스의 코드이다.

public class ArticleService {
    private ArticleDao articleDao;

    public ArticleService() {
        articleDao = Container.articleDao;
    }
    public List<Article> getForPrintArticles(String searchKeyword) {
        return articleDao.getForPrintArticles(searchKeyword);
    }

    public Article getArticleById(int id) {
        return articleDao.getArticleById(id);
    }

    public void remove(Article foundArticle) {
        articleDao.remove(foundArticle);
    }

    public void add(Article article) {
        articleDao.add(article);
    }

    public int getNewId() {
        return articleDao.getNewId();
    }
}

 

 

2. 회원 관련 로직

• Main 클래스부터 프로그램이 진행되는 순서는 다음과 같다.
• 프로그램의 진행 순서는 무조건 단방향이며, 절대 역순으로 실행될 수 없다.
• Main -> App -> Controller -> MemberController -> Container -> MemberService -> Dao -> MemberDao의 순서이다.
• Main에서 시작해서 App에서 각 Controller로 요청 및 라우팅, 요청응대, 실제 기능 수행, DB 관리의 순서라고 생각하면 좋다.
• 리포지터리를 통해 추가 및 수정된 코드를 보면, 핵심 기능 역할을 하는 메서드는 그대로 유지되고, 프로그램의 진행순서를 맞춰 전체적인 구조가 수정되었다.
• 앞으로는 무조건 Controller에서 명령어의 요청을 받고, MemberController에서는 MemberService를 거치지 않고 절대 MemberDao로 연결될 수 없다.
• 다시 말해 MemberController.java 클래스에서 Dao라고 써있는 변수나 메서드가 없어야 정상인 것이다.

 

• 다음은 추가된 MemberService.java 클래스의 코드이다.

public class MemberService {
    private MemberDao memberDao;

    public MemberService() {
        memberDao = Container.memberDao;
    }

    public void join(Member member) {
        memberDao.join(member);
    }

    public Member getMemberByLoginId(String loginId) {
        return memberDao.getMemberByLoginId(loginId);
    }

    public int getMemberIndexByLoginId(String loginId) {
        return memberDao.getMemberIndexByLoginId(loginId);
    }

    public int getNewId() {
        return memberDao.getNewId();
    }
}