Map<String, dynamic> 방식

Map<String, dynamic>를 써야 타입 변환이 자유롭고 나중에 필드값 추가하기 용이하다

Json과도 호환이 잘된다

DocumentSnapshot 는 타입 변환도 힘들고 호환이 잘 안된다.

 

Q1. ProductModel이 Firestore의 DocumentSnapshot을 직접 처리해야 한다는 건 무슨 의미인가요?

A1: DocumentSnapshot은 Firestore에서 데이터를 가져올 때 사용하는 Firestore 고유의 데이터 타입입니다. 만약 ProductModel이 DocumentSnapshot을 직접 처리하도록 작성되어 있다면, 모델 클래스가 Firestore에 종속되어 Firestore에서 가져온 데이터만을 처리할 수 있게 됩니다. 다른 데이터 소스, 예를 들어 JSON 파일이나 로컬 데이터베이스에서 온 데이터를 그대로 사용할 수 없습니다.

---

Q2. ProductModel이 Firestore에 종속된다는 것이 필드 추가나 관리에 불편함을 준다는 건 무슨 의미인가요?

A2: ProductModel이 Firestore의 DocumentSnapshot을 직접 사용하게 되면, 새로운 필드를 추가하거나 변경할 때 Firestore의 데이터 구조에 맞춰야 하기 때문에 코드가 복잡해질 수 있습니다. Firestore 외부의 데이터(JSON, 로컬 데이터베이스 등)는 DocumentSnapshot 타입이 아니므로 fromFirestore와 같은 생성자를 그대로 사용할 수 없어 관리가 어렵습니다.

---

Q3. 왜 Map<String, dynamic>을 사용하면 나중에 필드 추가가 쉬워지나요?

A3: Map<String, dynamic>은 다양한 데이터 소스(JSON, Firestore, 로컬 DB 등)에서 데이터를 가져올 때 모두 호환 가능한 형식입니다. Firestore의 DocumentSnapshot도 Map<String, dynamic>으로 변환할 수 있기 때문에, fromMap 생성자를 사용하면 Firestore뿐만 아니라 다른 소스에서 온 데이터도 쉽게 처리할 수 있습니다. 이렇게 하면 모델이 특정 데이터 소스에 종속되지 않고, 다양한 필드 추가나 수정에도 유연하게 대처할 수 있습니다.

---

Q4. Firestore의 DocumentSnapshot에 의존하는 방식은 필드 추가가 왜 어려운가요?

A4: DocumentSnapshot은 Firestore 전용 타입으로, Firestore에서 가져온 데이터에만 사용할 수 있습니다. 만약 Firestore 외의 다른 데이터(JSON, API 응답 등)를 통해 필드를 추가하거나 수정해야 한다면, DocumentSnapshot 타입에 맞추기 위해 복잡한 변환 작업이 필요합니다. 반면, Map<String, dynamic>을 사용하면 Firestore와 JSON 데이터를 동일하게 처리할 수 있어 필드 관리가 훨씬 쉬워집니다.

---

Q5. Map<String, dynamic> 방식이 Firestore 외부 데이터에서 사용될 때의 장점은 무엇인가요?

A5: Map<String, dynamic>을 사용하면 JSON, 로컬 데이터베이스, API 응답 등 다양한 데이터 소스에서도 일관되게 ProductModel을 생성할 수 있습니다. Map<String, dynamic>은 Dart에서 가장 기본적인 데이터 타입으로, 다양한 데이터 소스와의 호환성이 높아 모델 클래스가 특정 데이터 소스에 종속되지 않고 독립적으로 동작할 수 있습니다. 따라서, Firestore뿐 아니라 다른 데이터 소스에서도 유연하게 사용할 수 있습니다.

---

이렇게 Map<String, dynamic>을 사용하는 방식이 확장성과 유연성을 제공하여 다양한 데이터 소스에서도 일관된 처리가 가능하다는 것이 주요 장점입니다.