comtK

안녕하세요 콤트입니다.

이번에는 MVC 패턴에 대해서 이야기해보겠습니다.

Model View Controller의 약자입니다.

어플리케이션을 크게 모델, 뷰, 컨트롤러로 구분하고, 결합도를 최소화 하는 패턴이라고 합니다.

각 부분들에 대해 이야기해보겠습니다.

모델은 어플리케이션의 비즈니스 로직 부분을 이야기합니다.

DB에서 데이터를 가져오고, 어플리케이션에 필요한 서비스를 수행하는 부분입니다.

뷰는 말그대로 사용자에게 보여지는 영역입니다.

JSP 파일이 주를 이룹니다. 모델에서 처리하여 보내진 정보를 보여주는 영역입니다.

컨트롤러는 모델과 뷰 사이에서 요청의 흐름을 컨트롤하는 부분입니다.

사용자의 요청을 받아들이면, 컨트롤러는 요청에 해당하는 비즈니스 로직을 호출하여 요청을 처리학나, 데이터를 가져오거나 처리하고, 결과를 뷰로 포워딩하여 사용자가 결과를 확인하게하는 기능을 합니다.

MVC 패턴에는 모델1과 모델2가 존재합니다.

각각의 모델에 대해서 알아봅시다.

* 용어설명

DTO : Data Transfer Object의 약자로 데이터를 담아 움직이는 객체를 뜻합니다.

사용자가 입력한 데이터(회원가입 정보, 로그인시 계정 및 패스워드 등등)나, 사용자가 요청한 데이터(게시판 목록, 게시글 내용 등등)을 담아서 흐름을 따라 움직입니다.

DAO : Data Access Object의 약자로 데이터를 저장하고있는 데이터베이스에 접근하는 객체입니다.

사용자가 요청한 데이터가 DTO에 담겨져서 넘어오면 DAO는 DTO에 있는 데이터들을 이용하여 DBMS에 쿼리를 날려서 데이터를 저장하거나, 가져옵니다. 

모델1은 컨트롤러 부분과 뷰 부분이 같이있다고 생각하시면 됩니다.

(이미지 출처 : http://blog.daum.net/gunsu0j/165)

위 이미지를 보시면 컨트롤러와 뷰가 같이 존재합니다.

사용자가 페이지에 접근하면, JSP 페이지 내에서 직접 비즈니스로직을 호출하여 요청을 처리하고 그 결과를 그대로 JSP페이지에 전달하여 사용자에게 보여지게 됩니다. JSP 페이지 내에서 스크립트릿(<% %>)으로 자바코드를 작성하여 비즈니스로직 클래스를 import하고, 메소드를 호출하여 나온 결과값을 그대로 처리한다고 생각하시면 됩니다.

* 장점

1. 개발 초기에 크게 설정이 필요가 없어 빠른 개발이 가능하다.

2. 복잡한 설정이 들어가지 않기떄문에, 접근이 용이하다.

* 단점

1. 컨트롤러와 뷰가 같이 묶여있어 병행작업이 힘들다.

ex) 페이지의 비즈니스로직 부분과, 뷰 부분에 수정사항이 생겼을 경우, 비즈니스로직과 뷰 부분이 같은파일에 있기 때문에 작업이 순차적으로 진행되어야한다.

만약 SVN이나 git을 이용하여 코드를 공유할 경우, 각자의 PC에 있는 파일로 작업한 후에 커밋을 하면, 충돌이 일어나서 코드를 정리해주어야 한다. 이를 막기위해선 한사람이 수정을 끝낸후에 커밋을 하면, 다음사람이 커밋내용을 업데이트 받아서 작업을 진행하여야 한다.

2. 자바 코드와, JSP & HTML 이 섞이기 때문에 코드가 복잡해진다.

모델2는 모델1에서 뷰와 컨트롤러가 나뉘었다고 생각하시면 됩니다.

(이미지 출처 : http://blog.daum.net/gunsu0j/165)

모델1 이미지와 거의 비슷하지만, 컨트롤러와 뷰가 분리되어있는것을 볼 수 있습니다.

모델2로 작업을 진행할 경우 모델1에서 복잡했던 코드는 한층 간결해집니다. 사용자의 요청을 컨트롤러가 받아서 비즈니스로직을 호출한 후에, 처리된 결과를 컨트롤러가 뷰로 포워딩해줍니다. 이로서 뷰는 넘겨받은 결과에 대한 화면을 보여주기만 하면 됩니다.

* 장점

1. 모델1에 비해서 코드가 한결 간결해진다.

2. 분리된 코드로 인하여 유지보수가 편해진다.

3. 확장이 용이하다.

* 단점

1. 개발 초기에 설정이 필요한 부분이 모델1보다는 많기때문에 실질적인 작업이 들어가기까지 시간이 걸린다.

2. 개발자가 모델2 아키텍쳐에 대한 이해가 필요하다.

(모델1 역시 이해가 필요하지만, 그보다 더 수준높은 이해를 필요로 한다.)

3. 코드가 분리되면서 관리해야할 파일이 많아진다.

안녕하세요~ 공부를 시작하는데 정리하면서 같이 공유도 할겸 블로깅을 시작하게되었습니다.

혹시 생각하시는것과 다른것이 있거나, 혹은 틀린부분이 있다면 알고게시지만말고 알려주세요!!

오늘은 제가 항상 헷갈려하는 메소드 오버로딩과 오버라이딩에 대해서 정리를 해볼까 합니다.

정리하면서 개념좀 확실히 잡혀서 안헷갈렸으면 하는 바램이 있어요ㅠ

시작합니다!

메소드 오버로딩은 하나의 클래스 안에서 같은 이름의 메소드를 여럿 생성하는것이라고 보시면 됩니다.

그런데 메소드명이 같으면, 메소드를 호출할때 어떻게 구분할까요?? 같은 이름의 메소드들 사이에 뭔가 차이점이 있으니 그걸 통해서 각각 구분을 하는거겠죠? 그 차이점은 크게 3가지로 볼수있습니다.

먼저 기존의 메소드를 확인하겠습니다.

1. 인자의 자료형

인자의 자료형 역시 메소드를 구분하는 기준점이 됩니다.

2. 인자의 갯수

같은 메소드명이 여러개있을때 인자의 갯수에 따라 구별이 가능합니다.

3. 인자의 순서

메소드가 넘겨받는 인자의 순서도 역시 메소드를 구분하는데 영향을 미칩니다.

4. 메소드를 호출

메소드를 호출할때의 모습입니다.

이런식으로 호출할때 어떤 메소드를 사용할지 알 수 있습니다.

툴에따라 다를수도 있어요..!!

이렇게 하나의 클래스 내에서 같은목적을 갖고있는 메소드들에게 같은 이름을 사용하려할때 메소드명을 목적에 맞게 지정해주면서 각 메소드들마다의 동작을 할 수 있게끔 하는것을 메소드 오버로딩 이라고 합니다.

메소드 오버라이딩은 하위 클래스에서 상위 클래스를 상속받아서 사용할 경우, 상위클래스에서 정의된 메소드를 하위클래스에서 필요에 맞게 재정의하여 사용하는것을 말합니다.

예를들어서 작업을 하는데 있어서 직상 상사 또는 선배와 같이 일을하는데, 이사람이

'이런 기능을 하는게 필요할거야. 내가 만들어뒀으니 그냥 써 찡긋★'

하면서 클래스를 하나 던져줬습니다. 그래서 '감사합니다!!' 하고 받아서 쓰고있는데 사용하다보니 제한이 있는걸 알게되었습니다. 그래서 클래스를 열어봤더니 매우 마음에 들지 않는거죠.

예시를 들면서 짰지만 정말 마음에 들지 않아요. 뭐 갯수가 한정되어있다면 할말없긴하지만... 여하튼!

이걸 전해받은 거는 정말 너무 싫었어요. 그런데 이걸 수정하자니 우리 착한 선배 or 상사님께 상처가 될까 말하기도 좀 그런겁니다. 그래서 저는 이렇게 다시 짜기로 했어요.

이렇게 하였을 경우 위의 방식보다는 활용도가 높죠. 경우에 따라 다르긴 하겠지만 적어도 글자수에 제한은 없으니까요. 제가 오버라이딩한 메소드와 상위클래스의 메소드의 결과를 비교해볼까요.

위아래 결과가 다른것을 확인할 수 있습니다.

위의 결과값은 0~9까지 10개의 문자를 입력해도 최대 8까지밖에 나오지 않아요.

그러나 아래는 입력한 만큼 별이 찍힙니다. 글자수에 제한을 두고싶지 않아서 재정의하여 사용한것입니다.

지금 이 상황은 제가 어거지로 만든겁니다. 그냥 설명하는거보다 이미지로 남는게 좀 더 쉽게 기억되지 않을까 하는 마음에... 그리고 위에서 이렇게 짜주는경우는 정말 흔치않아요. 그건 너무하잖아요..ㅠㅠ (혹시 있을지도 모르니 절대라고는 말 못하겠습니다.)

지금처럼 상위클래스의 내용을 하위클래스에서 필요에 맞게 재정의하여 사용하는것을 오버라이딩이라고 합니다.

오늘 작업한 내용을 파일로 올려놓을께요!!

method.zip

다음에는 또 다른거 정리해야지.