밑에서 레포지터리 패턴에 대한 이야기가 나왔는데,


무조건 DB만 쓰는데 인터페이스를 만들어 분리를 할 필요가 있겠냐는 주장이 있다고 한다.


닷넷에서 개발을 거의 안해봐서 어떤진 모르겠으나 (해보긴 했어도 너무 옛날 얘기라)


레포지터리 패턴이 주는 장점은 보안과 캐싱 기능을 빼놓을 순 없을 것 같다.

원칙적인 패턴에서는 그런 서브 기능에 대해서는 언급이 없지만 실전에서는 저 기능 때문에 쓰게 되는듯.


데이터를 주로 DB에 쓴다고 할지라도. ORM 이나 레퍼로 감싸면 좋은 이유는.


쿼리실행전 인젝션 검증이나, 잘못된 권한처리등 보안 요소를 낑궈 넣기 좋은 위치가 되어줌.

그리고 레코드 반환에서도 자동 컨버팅이나 이런걸 박아두기도 좋음.


그리고 라이브에선 매번 호출 때마다 DB를 억세스하는게 좋은 방식은 아니므로.

Read가 대부분인 "사이트 설정", "게시판 설정" 과 같은 녀석들 경우에는

특정 테이블을 조회할 때면 TTL(유효시간)을 달아서 인스턴스 내의 메모리에서 바로 찾아서 리턴할 수 있게

후크를 넣어줄 수 있는 위치가 되어 줌.

(요즘은 DB에서도 캐싱해서 바로 반환 해주겠지만)


개발자 입장에선 그냥 캐시고 보안이고 나발이고 신경 끄고 ORM 사용할 때랑 거의 똑같이 쓸 수 있는거지.

레포 클래스에서 알아서 저걸 해준다고 보고. 근데 요즘엔 이게 대부분 ORM이나 프레임워크로 지원하는 듯.


요즘엔 DB, Redis, in-memory. 정도에서 알아서 꺼내서 보여주는 정도 일듯.

내 경우에는 특정 테이블의 insert 또는 update의 경우에는 직접 처리하지 않고 큐에 넣어서 다른 프로세스가 처리하도록 해버림.

이걸 레포에 붙인 케이스가 있음. 근데 이걸 레포 패턴이라 할 수가 있나 모르겠네.


암튼.. 뭐 그러타고.