콘텐츠 공급자 vs 직접 데이터베이스 액세스 (트랜잭션 관리)

Question

적어도 필자는 콘텐츠 공급자와 SQLite 데이터베이스에 직접 액세스하는 기본적인 차이점을 알고 있습니다. 내 응용 프로그램에 작동하는 프로토 타입이 있고 현재는 데이터베이스에 직접 연결됩니다. Content Provider 패턴을 사용한 경험이 없지만 다른 응용 프로그램과 일부 데이터를 공유해야한다는 것을 알았습니다.

12 개 정도의 테이블 중 약 2 개만 공유하므로 콘텐츠 공급자 패턴을 따르기 위해 데이터 레이어를 완전히 다시 실행해야하는지 또는 콘텐츠 공급자를 통해 해당 테이블 만 노출해야하는지 궁금합니다. 다른 응용 프로그램을 위해 여전히 기본 응용 프로그램의 데이터베이스에 직접 액세스 할 수 있습니다.

필자의 프로토 타입과 관련하여 겪었던 문제점 중 하나는 상당히 복잡한 트랜잭션이 있었고, 코드를 작성하기 위해 작성한 코드가 특별히 잘 설계되지 않았고 전혀 재사용 할 수 없다는 것입니다. 이 앱에 더 많은 기능을 추가함에 따라 필자는 직접 작성하기 전에 더 나은 데이터 액세스 레이어를 설계해야 할 것입니다. 이미 이런 유형의 디자인 패턴을 가진 훌륭한 리소스를 알고 있습니까? 또한 콘텐츠 공급자 경로를 사용해야하는 경우 데이터베이스 트랜잭션을 안전하게 제어 할 수 있습니까?

Answer 1

직접적인 데이터베이스 코드 위에 필요한 기능으로 콘텐츠 제공 업체를 만드는 데 문제가 없어야한다고 생각하지 않습니다. 컨텐츠 제공자는 실제로 SQLite와 매우 흡사하게 보이는 구조화 된 데이터에 액세스하기위한 추상화입니다. :) 앱의 다양한 내부 부품이 공급자와 동일한 데이터베이스에 직접 액세스하는 경우 두 코드가 함께 훌륭하게 연동되는 한 괜찮습니다.

저는 사실 "항상 콘텐츠 제공자를 사용해야합니다."에 대해 절대적인 팬이 아닙니다. 컨텐트 공급자가 필요하지 않은 경우 컨텐트 공급자를 사용하지 마십시오. 더 쉬운 SQLite를 직접 처리하십시오. 다른 앱과의 특정 상호 작용을 위해 콘텐츠 제공 업체가 필요한 경우 앱이 내부적으로 데이터베이스에서 수행하는 모든 작업을 지원하는 큰 복잡한 작업없이 자유롭게 콘텐츠를 작성할 수 있습니다. 이것이 더 쉬운 경우에, 중대하다. 또한 실수로 개인 데이터를 앱에서 다른 사용자에게 노출하는 가능성을 줄입니다.

Answer 2

나를 인용하지 마십시오.하지만 콘텐츠 제공 업체가 데이터를 객체에 제공하는 방식을 추상화하는 방법이라고 확신합니다. 이 방법은 객체가 공급자와 통신 할 수 있으며 구현 방법, 즉 데이터가 저장되는 위치와 위치는 신경 쓰지 않습니다. 어쩌면 미래에 데이터를 저장하는 다른 방법을 제공하고 콘텐츠 제공 패러다임을 사용하면 인터페이스 기반 통신이기 때문에 재 작업을 줄일 수 있습니다.

내가 할 수있는 모든 곳에서 Android 디자인 패턴을 사용합니다. 솔직히 말해서, 나는 지금 내 프로젝트에서 이것을해야만한다.