요즘 바빠서 블로그고 뭐고 힘들다 그리고 글을 쓰고있는데 주제가 너무 광범위하고 어려워서 callAdapter 할때같이 하나를 너무 오래 하고있다.
스터디에서 간만에 기록할만한 내용이 나와서 글로 정리했다.
Room
안드로이드 진영의 ORM인 Room에 대해 다루는 장이였다.
sqlite를 기반으로 구글에서 만든 라이브러리로써 편리하게 sqlite를 사용할수있도록 만들었다.
사실상 sqlite를 사용해보면 그냥 Room은 그때그때 사용법을 보면 사용할 수 있을정도의 수준이다.
현재 책에서 나온 단순 사용법은 SQL을 날것 그대로 사용하는 형태인 @Query를 제외하고도 단순한 crud는 제공함으로 이 기능도 이용하자
[Room 공식문서] https://developer.android.com/training/data-storage/room?hl=ko
오히려 이번장의 주제는
- Room 을 구성하는 주체인 DB에 관한개념
- 맨날 헷갈리는 DAO,DTO,VO,ENTITY 같은 용어
- SQL에 대한 이해도(chatgpt로 대충 해결가능)
- 아키텍쳐 패턴 관점에서의 의존성 주입 및 싱글턴에 대한 사용
이렇게가 메인이 아닌가 생각이 든다.
각각의 주제들에 대한 나의 생각을 짧게 아주 짧게 작성해보려한다.
1. Room 을 구성하는 주체인 DB에 관한개념
구글 공식문서에서 나온 Room에 대한 설명이다.
뭔가 서버에 대한 공부를 하는것과 같아보이는데
실제로 서버에서도 이런 개념과 용어가 쓰이고 데이터를 꺼내오는 형태가 같다고 한다.
(상위에 ORM(계층?)을 두기도 하는데 여기서는 Room 자체가 ORM이니 뜻이 통할것이다.) -> 자바진영에서 제일 유명한 ORM은 JPA라고 한다.
ORM 이라고 말하면 뭔가 어려워 보이지만 한마디로 언어와 DB사이의 Mapper이다.
자바스크립트에서는 Prisma 같은게 있고 (뭐 다양하게 많은것같다.)
자바에서는 JPA
안드로이드에서는 ROOM인것이다. 안드로이드에서는 부가적인 편의성을 더 제공하는것같지만(이런 편의성을 Spring data jpa 가 서버에서 더 편리하게 제공한다고 ...)
개념을 이해하고 싶다면 밈이 떡칠되어있지만 사실 난 코딩애플이 생각보다 와닿게 설명해서 봐보면 도움이 될수도 있을것 같다.
https://www.youtube.com/watch?v=8TnUKFs-zH0 이거 한번 봐보자
어쨋든 뭔가 안드로이드여도 계속 공부하다보니 서버의 개념과 관점도 비슷하게 영점이 맞아가는것 같다.
Entity를 생성하여 DB를 정의하고
DAO(서버 JPA상에서는 Repository로 사용한다고함 -> DAO가 해야하는 역할인 DB에 가까운 데이터 접근을 Spring Data JPA가 추상화해서 제공하기에 Reproitory로 해결이 가능하다고 한다. 만약 JPA를 사용하지 않는다는 개념이라면 JDBC 템플릿을 사용하는 경우가 많고 이때는 명확하게 Repository와 DAO를 나눠서 역할분리를 한다고 한다.)를 통해 DB에 접근하고
실제 데이터 베이스의 개념은 관계형 데이터베이스로 동일하다.
처음에 아무것도 모를때는 Room을 개쩌는 구글 개발자가 만든거라고 생각했는데 걍 서버에서 널리쓰이는 개념을 완전 베껴왔다.
물론 서버랑 관점에 차이가 있어서 그런지 용어가 살짝 다르다(안드는 DAO, 서버는 Repository 두개의 경계선을 명확하게 가져가지 않는다면 한쪽이 다른 한쪽에 흡수되게 될텐데 그런 부분에서 더 중요하게 여기는 부분을 용어로 정의하지않았나 싶다. -> 내 의견임 ^^)
2. 맨날 헷갈리는 DAO,DTO,VO,ENTITY 같은 용어
이 용어정리는 서버 관점으로 정리해보았다.
Room은 서버관점에서 바라보는것도 맞다고 생각하여 서버 크루원들과 대화내용을 배경으로 작성해보았다.
- DAO
DAO는 그야말로 Data Access Object DB에 접근하는 프로그램 말단에 존재하는 클래스(계층)이다.
관점에 따라 다르겠지만 DAO는 데이터베이스에 가까운 단순한 crud를 처리하는 용도로 쓰이는것이 일반적이다.
(도메인적인 복잡한 조합은 도메인에 가까운 계층에서 처리하는것이 합당하다고 생각한다.)
물론 DAO와 Repository를 혼용 혹은 단순화하여 사용하기 위하여 DAO 혹은 Repository중 하나를 합쳐서 사용하기도 하지만
만약 DAO 와 Repository를 분리하였다면 각각의 책임을 캡슐화하여 Dao는 DB에 가까운 로직 Repository는 도메인의 가까운 로직을 각각 캡슐화 하는것이 맞다고 생각한다.
여담으로 Room 에서 간단한 insert같은것들을 sql이 필요없이 추상화하여 사용할수있도록 지원하는것 처럼 서버에서는 Spring Data JPA에서 훨씬 다양하고 많은 기능들을 추상화해서 제공하기 때문에 DAO를 사용하기 보다는 Repository하나로 다 해결하는 경우가 많다고 한다.
- DTO
Data Transfer Object 로 실제로 로직이 없이 그야말로 데이터를 전달하는 용도로만 사용한다.
계층을 분리하다 보면 각각의 계층별 모델이 생기기 마련이고 그 계층간 데이터를 전달하기위해 순수 전달만을 위한 객체를 만들게된다.
이것이 DTO이고 계층간의 데이터 전달 역할을 담당한다.
사실상 서버에서는 숨쉬듯이 자연스러운 이야기같은데 안드로이드 개발하면서는 DTO라는 용어를 생각보다 쉽게 접할일도 Ui layer에서 진정한 의미의 모델이 아닌 DTO라고 불러도 무방한 객체를 사용하기도 하는데 DTO가 무엇인지 알면서 이렇게 각 layer별 model의 의미가 퇴색되지 않도록 잘 이용해야 할것이다.
- VO
값 객체이다. 값이라 하면 뭐가 생각나는가? 1,2,3 이런 수학적인 값이 생각난다.(나만 그런가?) 어쨋든 이런 수학적인 값들은 변할수없다. 1이 2로 부른다고 달라지는가? 1은 영원히 하나만 있다는것을 뜻한다.
이렇듯 값객체는 값의 의미로 쓰이는 객체이고 불변인것이 키포인트이다.
또한 로직을 가질수 있어 각 값이 가지는 행위들을 캡슐화하여 활용할 수 있다.
- ENTITY
https://tecoble.techcourse.co.kr/post/2021-05-16-dto-vs-vo-vs-entity/ 이글에 나와있는 Entity 에 대해 나와있는것이다. Entity는 실제 DB 테이블과 매핑되는 핵심 클래스이다. 이를 기준으로 테이블이 생성되고 스키마가 변경된다. 따라서, 절대로 Entity를 요청이나 응답값을 전달하는 클래스로 사용해서는 안 된다.
결론적으로 관계형 Db는 표 아닌가? 표에서 이거다 (빨간박스가 나타내는 것 용어가 잘 생각안남) 어쨋든 표에서 이부분을 나타내는데
관계형 데이터베이스에서 가장 기본이되는 클래스이고 가장 단순화 시켜서 구현 했을때도 항상 필수적으로 존재한다.
고로 가장 단순화해서 domain 을 분리하지않고(가장 단순하고 빠르게 구현하기위해) 혼용해서 사용했을때는 로직이 들어가지만
Layer의 분리를 확실히하고 Domain의 역할이 확실하다면 db의 필드를 매핑하는 역할을 할뿐
비지니스 로직은 다 도메인으로 넘어가는 형태를 취한다. 고로 로직이 없어지게 된다.
하지만 JPA에서 많은것들을 제공하기 때문에 하위의 단순한 로직을 담당하던 Layer의 필요성이 모호해지기 때문에 사실상 없어지고
Entity자체를 도메인스럽게 사용하기도 한다고 한다.(이건 쟁점이 될듯하다.)
3. SQL에 대한 이해도(chatgpt로 대충 해결가능)
이건 Room 쓸려면 어짜피 알아서 공부해야한다.
room 에도 join 왜래키 어쩌구 저쩌구 다있으니까 공부하자
4. 아키텍쳐 패턴 관점에서의 의존성 주입 및 싱글턴에 대한 사용
이건 이글에 쓰려면 너무 길고 양도 많기 때문에 간단 요약을 하자면
싱글톤을 쓰려면 DI등등 의존성에 관련된 대비책이 필요할것이고. 싱글톤으로 생성하는 충분한 이유와 관리를 생각해봐야할것이다.
또한 아키텍쳐 패턴적인의미로 안드로이드 의존성이 어디까지 침범할것인가를 생각해보고 안드로이드에 맞는 형태로 아키텍쳐 패턴 및 기술들을 고려해야한다고 생각한다.
'책을 읽어보자 > 실무에 바로 적용하는 안드로이드 프로그래밍' 카테고리의 다른 글
| [제이슨 권장도서] 실무에 바로 적용하는 안드로이드 프로그래밍 2장 (0) | 2023.05.27 |
|---|
