Controller / Service / Dao 의 lifecycle 에 관한 질문

[이호훈]

안녕하세요.

예전부터 의문이 들었던 것 중에 Controller / Service / Dao 의 lifecycle 에 관한 것을 여쭤보고자 합니다.

제가 정리가 안된 상태에서 여쭤보려니 많이 헷갈리네요 ^^;;

일반적으로 Controller는 url 호출시에 생성이 되고 응답 후에 소멸이 되는 것으로 알고 있고,

Service / Dao 는 Singleton 이라고 알고 있습니다. 이게 맞는가요??

그 다음으로 환경설정(.xml)에 컨트롤러 등록시 기본적으로 isSingleton=false 셋팅안하게 되면 싱글톤으로 생성된다고 하는데 이것도 맞는지 영????

그리고 어노테이션을 이용하여 컨트롤러/서비스/dao등을 생성하게 될 때도 싱글톤으로 생성이 되는 것인지..

싱글톤으로 생성이 되면 멤버 변수 공유 문제라던지 여러가지 문제가 발생되지 않나요??

컨트롤러에서 Service 호출하고 Service에서 dao 호출하게 되는데 각각이 독립된 메모리영역에 올라가는게 아니라 Service와 Dao만 싱글톤 객체로 있게 된다면 그 안에 구현된

코드 중에 멤버변수 공유 문제가 생길 것 같다는 생각이 들어서요..

정리안되고 있는 저의 머리속에 이론들을 정리 좀 부탁드리겠습니다^^;;

[박성철]

> 안녕하세요.

안녕하세요. ^^

> 일반적으로 Controller는 url 호출시에 생성이 되고 응답 후에 소멸이 되는 것으로 알고 있고,
> Service / Dao 는 Singleton 이라고 알고 있습니다. 이게 맞는가요??

예외는 있지만 spring mvc의 컨트롤는 싱글톤이고 service랑 dao도 보통 싱글톤으로 씁니다.

> 그 다음으로 환경설정(.xml)에 컨트롤러 등록시 기본적으로 isSingleton=false 셋팅안하게 되면 싱글톤으로 생성된다고 하는데
> 이것도 맞는지 영????

예전에는 XML에서 <bean ...> tag 사용해 설정할 때에 singleton 속성을 써서 싱글톤 여부를 지정했습니다.

singleton="true"

요즘은 scope라는 속성을 쓰고요.

scope="singleton"

하지만 빈 등록시 scope 지정을 하지 않으면 싱글톤으로 만들어지니까 생략해도 됩니다.

> 그리고 어노테이션을 이용하여 컨트롤러/서비스/dao등을 생성하게 될 때도 싱글톤으로 생성이 되는 것인지..

기본은 싱글톤입니다. @Scope를 써서 다른 것으로 바꾸지 않는다면...

> 싱글톤으로 생성이 되면 멤버 변수 공유 문제라던지 여러가지 문제가 발생되지 않나요??

예. 그래서 싱글톤인 빈은 원칙적으로 상태(작동하는 중 값이 바뀌는 멤버 변수)를 가지지 않는 것이 좋습니다.

> 컨트롤러에서 Service 호출하고 Service에서 dao 호출하게 되는데 각각이 독립된 메모리영역에 올라가는게 아니라 Service와
> Dao만 싱글톤 객체로 있게 된다면 그 안에 구현된
> 코드 중에 멤버변수 공유 문제가 생길 것 같다는 생각이 들어서요..

동시성은 늘 신경써야겠죠. 위에서 처럼 상태를 가지지 않는 것이 가장 좋고 상태를 갖고 있어야 한다면 동시성에 신경을 써줘야 합
니다.

동시성 때문에 싱글톤 대신 프로토타입 같은 스코프를 써야 한다면 그냥 싱글톤으로 쓰되 상태를 메세지를 보내는 쪽에서 객체로 만들
어 파라메터로 보내고 서비스나 DAO에서는 이 객체에 상태를 저장하는 방식을 쓰는 것도 좋습니다.

서비스나 DAO에 어떤 상태를 가지고 있는지 예를 보여주시면 해법을 더 정확히 말씀드릴 수 있을 것 같습니다.

[김성윤]

싱글톤 이야기가 나와서 그런데요..

스프링의 scope 의 싱글톤이 일반적으로 생각하는 싱글톤 패턴으로 생성된 거랑 다르다고 하던데.. ?

맞나요 ?

2009년 9월 24일오후 5:24, 박성철 <gyu...@gmail.com>님의 말:

[윤희한(성철)]

일반적인 싱글톤은 한번 생성되면 JVM 단에서 단 하나의 인스턴스만 생성되는것이고

스프링은 최초에 프레임웍 로딩시에  생성한 bean 들이 스프링에서 관리하는 bean 풀같은곳에 저장되어

getBean해서 가져올때 해당 풀에서 가져오는것으로 알고있습니다.

그래서 xml 에다가 동일한 타입의 이름만 다른 여러개의 빈을 등록하면 스프링에서는 같은타입의 서로다른 빈이 생성되고

일반적인 싱글톤은 무조건 하나가 되는것으로 알고있습니다.

2009년 9월 24일오후 6:14, 김성윤 <helol...@gmail.com>님의 말:

[백기선]

@성윤 그러니까 4장을 읽으라니깐;; p139 Avoid Proliferation of Singletones by Using Application Resistry

2009년 9월 24일오후 6:14, 김성윤 <helol...@gmail.com>님의 말:

싱글톤 이야기가 나와서 그런데요..

--
좋은 하루 되세요~

[윤희한(성철)]

말이 또 꼬였네요 ㅜ.ㅜ 에효. 알고있는것도 전달을 못하네요 ㅜ.ㅜ

2009년 9월 24일오후 6:24, 윤희한 <ryys...@gmail.com>님의 말:

[성윤]

그럼 Resistry에서 뽑아주는 방식인 스프링의 singletone 방식이
singletone 패턴으로 생성하는 객체 보다 좋은 장점이 머가 있으려나요? ;;

@기선형 손발이 잘 안맞군요.. ㄷㄷㄷ

On 9월24일, 오후6시24분, 윤희한(성철) <ryys1...@gmail.com> wrote:
> 말이 또 꼬였네요 ㅜ.ㅜ 에효. 알고있는것도 전달을 못하네요 ㅜ.ㅜ
>

> 2009년 9월 24일오후 6:24, 윤희한 <ryys1...@gmail.com>님의 말:

>
> > 일반적인 싱글톤은 한번 생성되면 JVM 단에서 단 하나의 인스턴스만 생성되는것이고
>
> > 스프링은 최초에 프레임웍 로딩시에 생성한 bean 들이 스프링에서 관리하는 bean 풀같은곳에 저장되어
>
> > getBean해서 가져올때 해당 풀에서 가져오는것으로 알고있습니다.
>
> > 그래서 xml 에다가 동일한 타입의 이름만 다른 여러개의 빈을 등록하면 스프링에서는 같은타입의 서로다른 빈이 생성되고
>
> > 일반적인 싱글톤은 무조건 하나가 되는것으로 알고있습니다.
>

> > 2009년 9월 24일오후 6:14, 김성윤 <helolsj...@gmail.com>님의 말:

[박용권]

싱글톤 패턴의 나쁜점에 대해서는 Misko hevery의 Global State and Singletons 에 잘 나와있다는데... 아무래도 영어라 크흑...ㅡㅜ;;

싱글톤 패턴은 전형적인 전역상태를 조장하고 설계상의 문제를 찾기 힘들게하며 무엇보다 테스트를 어렵게한다네요.

스태틱 메소드로 이루어진 싱글톤 패턴은 상속도 안되고, 다형성도 적용 불가하고, mocking 하기고 어렵다니.. 피하는게 좋겠지요 @_@a

그래서 싱글톤 패턴의 단점은 메우고 장점을 살리고자 나온 대안이 스프링의 싱글톤 레지스트리 컨테이너가 아닐깝쇼~!

public 생성자의 평범한 POJO를 만들어서 사용하되 컨테이너를 통해서 싱글톤으로 관리되도록 만들면 된다는거...!

그나저나... 여긴 KSUG 인데 우째 글은 봄싹 그룹스 메일을 보는거 같네요... 대략 채팅모드?

2009년 9월 24일오후 8:11, 성윤 <helol...@gmail.com>님의 말:

[백기선]

싱글톤 스코프 말고 일반적인 싱글톤 클래스 구현체는 인터페이스 기반 프로그래밍을 하라는 객체지향원칙을 깨트리니까..

그게 좀 많이 별로 인듯.

2009년 9월 24일오후 8:53, 박용권 <arawn.kr@gmail.com>님의 말:

--
좋은 하루 되세요~

[Toby Lee]

싱글톤 스코프 말고 일반적인 싱글톤 클래스 구현체는 인터페이스 기반 프로그래밍을 하라는 객체지향원칙을 깨트리니까..

싱글톤도 인터페이스를 구현하게 할 수 있지.

생성이나 접근방식이 그렇다는 거지 인터페이스 기반 프로그래밍을 못하게 하지는 않는데. 

2009/9/24 백기선 <whites...@gmail.com>

싱글톤 스코프 말고 일반적인 싱글톤 클래스 구현체는 인터페이스 기반 프로그래밍을 하라는 객체지향원칙을 깨트리니까..

그게 좀 많이 별로 인듯.