원본 본문으로 이동하기

ORM 의 장점과 단점

박용서 - ORM의 장단점을 정리해 보았습니다. 필자도 여러 사이트에서 의견들을 모아서 정리하였기 때문에 참고 정도만 해주시기 바랍니다. 사실 필자는.. 프로시저 기반의 프로그래밍을 해서.. ORM을 거의 안쓰는 편이긴 합니다. - 필자는 ORM을 무조건 찬성/반대하는 입장이 아니며, 실무에서의 장단점 요약을 작성한 것 입니다. (ORM을 안쓰고 ORM에대해서 말하는건 좀 아닌것 같기에 최대한 조사를 바탕으로 작성했습니다.) 예를들어 가리사니의 주제글(현재화면)을 불러오는 경우. (전형적인 프로시저 패턴) // 실제 가리사니내 코드이며.. (설명/소스은닉)을 위해 네이밍만 한글로 치환했습니다. // 모든 뷰가 클라이언트(브라우저단)에 있음으로.. 서버에는 뷰가 없는 특이한 형태... // 가장 큰 단점은 필자가 함수정의문으로 만들어둔 함수이름.sql을 열어보기전까지 저 ?에 어떤 것이 들어가는지 알 수 없다는 겁니다. // 작성자가 아닌이상 SQL 폴더를 열어보기 전까진 저런 함수가 있는지도 알 수 없죠.. // 서블릿인데 service doGet post가 아닌이유는 이 부분은 필자가 만들어둔 서블릿 위에 올린 라이브러리에서 작동하기 때문입니다...... @Override public void main() throws Exception { useSession(); outText(); int 게시판분류코드= getParameterInt("받은게시판분류코드", 0); long 주제번호 = getParameterLong("받은주제번호", 0L); long 회원번호 = 회원번호가져오는함수(); if (게시판분류코드 > 0 && 주제번호 > 0) { getSQL("SELECT 조회수검사증가함수(?, ?::inet)") .set(1, 주제번호) .set(2, getIP()) .fn(); // 가리사니 모든 로직이 이런 형태를 가지고 있는데... 물론 단점도 많습니다.... // 비즈니스 모델이 전부 프로시저(pg-sql에선 함수)로 짜여있고 프로시저에서 // 이미 1개의 json으로 모두 만들어진 상태에서 서블릿은 단순히 SQL스트림을 응답스트림으로 출력만 하고있습니다. // SQL 출력중 오류가 발생할경우 [] 가 대신 출력되며, 오류사항은 DB에 기록 -> 실패시 파일기록으로 이어집니다. getSQL("SELECT 실제조회함수(?,?,?)") .set(1, 회원번호 ) .set(2, 게시판분류코드) .set(3, 주제번호) .fnStream("[]", out); } else { out.print("[]"); } } 제어역전의 관점에서 보면 불필요한 코드가 많다고 볼 수 있습니다. (여기서 제어역전이라고 해봐야.. 서블릿 컨테이너가 저 함수를 실행해준다는 것 밖에 없으니까요...) 이 코드를 보여드린 이유는.. ORM을 쓰지 않는 사람이 작성한 글임으로 직접 더 조사해보고 구현해본 후 장단점을 판단 해야 한다는 것을 다시한번 강조하는 것 입니다. 지금까지 프로시저/함수에 대해서 설명(?)했다면, 이번엔 ORM에 대해서 설명해 보겠습니다. ORM 이란? - https://en.wikipedia.org/wiki/Object-relational_mapping - Object-relational mapping 의 약자 - 아래 코드 처럼 좀더 객체-직관적인 소스를 만들어 낼 수 있다. // 일반적인 jdbc 접속 // 접속문 ~~~ 생략 / 위 백과사전의 참고한 것으로 Statement 를 기준으로 하였다. Statement stmt= conn.createStatement(); ResultSet rs = stmt.executeQuery("SELECT ... FROM persons WHERE id = 10"); if (rs.next()) { String name = rs.getString("FIRST_NAME"); } // ORM을 이용한 방법 : 물론 orm은 솔루션마다 방법이 다르며, 하나의 예제일뿐입니다. Person person = personRepository.getPerson(10); String name = person .getFirstName(); 장점 객체 지향적인 코드로 인해 더 직관적이고 비즈니스 로직에 더 집중하 수 있게 도와준다. - 선언문, 할당, 종료 같은 부수적인 코드가 없거나 급격히 줄어든다. - 각종 객체에 대한 코드를 별도로 작성하기 때문에 코드의 가독성을 올려준다. - SQL의 절차적이고 순차적인 접근이 아닌 객체 지향적인 접근으로 인해 가독 / 생산성이 증가한다. 재사용 및 유지보수의 편리성이 증가한다. - ORM은 독립적으로 작성되어있고, 해당 객체들을 재활용하여 사용할 수 있다. - 때문에 모델에서 가공된 데이터를 컨트롤러에 의해 뷰와 합쳐지는 형태로 디자인 패턴을 견고하게 다지는데 유리하다. - 매핑정보가 명확하여, ERD를 보는 것에 대한 의존도를 낮출 수 있다. DBMS에 대한 종속성이 줄어든다. - 대부분 ORM 솔루션은 DB에 종속적이지 않다. - 종속적이지 않다는것은 구현 방법 뿐만아니라 많은 솔루션에서 자료형 타입까지 유효하다. - 프로그래머는 Object에 집중함으로 극단적으로 DBMS를 교체하는 거대한 작업에도 비교적 적은 리스크와 시간이 소요된다. - 또한 자바에서 가공할경우 equals, hashCode의 오버라이드 같은 자바의 기능을 이용할 수 있고, 간결하고 빠른 가공이 가능하다. 단점 완벽한 ORM 으로만 서비스를 구현하기가 어렵다. - 사용하기는 편하지만 설계는 매우 신중하게 해야한다. - 프로젝트의 복잡성이 커질경우 난이도 또한 올라갈 수 있다. - 잘못 구현된 경우에 속도 저하 및 심각할 경우 일관성이 무너지는 문제점이 생길 수 있다. - 일부 자주 사용되는 대형 쿼리는 속도를 위해 SP를 쓰는등 별도의 튜닝이 필요한 경우가 있다. - DBMS의 고유 기능을 이용하기 어렵다. (하지만 이건 단점으로만 볼 수 없다 : 한 DBMS의 고유기능을 이용하면 이식성이 저하된다.) 프로시저가 많은 시스템에선 ORM의 객체 지향적인 장점을 활용하기 어렵다. - 이미 프로시저가 많은 시스템에선 다시 오브젝트로 바꿔야하며, 여기서 생산성저하나 리스크가 많이 발생할 수 있다. - 이론