Page History

ORM은 쿼리를 모르는 사람이 편리하게 사용할수 있는 툴일까? 로 시작하여

비교적 쉬운 데이터 모델은 ORM을(SQL PART-A) 통해 무난하게 학습진행되었지만

제가 원하는 진정한 변환은 SQL-PART2였으며 여기서 문제가 발생하였습니다.

이것의 변환을 위해 DB학습을 더해야했으며 표준적이지 않지만 해결방법을찾아야했습니다.

ORM은 DB를 이해하고 OOP로 변환하고 일치시키려는 컨셉을 가지고 있기때문에

DB와 OOP 연마를 함께해야하며 평균이상 더 해야한다란 결론에 도달하였습니다.

그러고도 복잡한 쿼리에대한 성능문제 예를 들면 N+1의 문제를 해결해야합니다.

ORM N+1 문제를 검색하면, 엄청난 량의 각기 다른문제를 검색할수 있으며

이것을 해결하는 표준적인 방법이 없으며  ORM을 사용하는 각각의 프레임워크마다 해결방식이 다릅니다.

ORM에 도전하기위해서는 기존개발 패러다임이 바뀌어야하고 다음과같은 더 고난이도의 해결해야할 과제가 있음을 알게되었습니다.

• 데이터 모델을 OOP로 완벽하게 표현하는것은 불가능하다. ( DB의 관계를 OOP의 상속으로 모두 해결할수 없습니다. )
• 데이터 마이그레이션은 항상 일어나는일이며, 이에대한 해결방식을 ORM 솔류션이 제공해야한다.
• DB 성능의 책임이 어플리케이션쪽에 어느정도 있으며, 결국 분산 처리라는 과제를 어플리케이션도 함께해야한다.
• 전통적인 CRUD 개발방법은 어느정도 안정성검증및 문화가 형성되어있으며, NOSQL이 이것을 모두 대처하는것은 아니며 여전히 중요합니다.
• ORM과 별개로 웹개발에서 OOP 가 실종되어간다. ORM은 DbRelation을 OOP로 표현하려는것이 본질이다.  OOP는 학습하지 않으면서 ORM이 쉬운길이라 생각하고 선택하려한다. 이것이 안티패턴이다.
• OOP 를 ORM과 함께 부활하려는 구체적인 패러다임의 구현체가 DDD+CQRS 이며,  개발문화의 변화및 수준높은 개발능력을 요구합니다. "ddd cqrs orm" 키워드로 검색을 해보면  꾀 꽤 높은수준의 DB 이해와 OOP활용 능력이 요구됨을 알수 있다.