Определить абсолютную лучшую практику для доступа к базе данных в ООП немного сложно.
Вы ударили ноготь по голове, что нужно учитывать множество факторов:
- как обрабатываются параметры конфигурации?
- приложение многопоточное? вам нужны пулы соединений с базой данных?
- нужна ли вам переносимость базы данных (т. Е. Используете ли вы разные БД при разработке и в производственном процессе? Вас беспокоит блокировка поставщика одной БД? Вы распространяете приложение для других пользователей, которые могут использовать другую БД?)
- Вас интересует защита ваших операторов SQL или централизованное применение других разрешений на доступ?
- Существует ли общая логика при выполнении некоторых вставок и обновлений, которые вы не хотели бы дублировать при каждом касании конкретной таблицы?
Из-за этого многие ООП тяготеют к структуре ORM для чего угодно, кроме самых простых случаев. Общая идея заключается в том, что логике вашего приложения не нужно напрямую взаимодействовать с базой данных: изолируйте ваш бизнес-код от фактического механизма персистентности как можно дольше.
Вместо этого попытайтесь спроектировать свое приложение так, чтобы ваша бизнес-логика взаимодействовала с уровнем модели. Другими словами, иметь в системе объекты модели, которые инкапсулируют и описывают ваши бизнес-данные. Эти объекты модели затем предоставляют методы для получения и сохранения их состояния в базе данных, но вашей логике не нужно заботиться об этом.
Например, допустим, в вашей системе есть понятие «человек». Вы, вероятно, смоделировали бы это как класс с некоторыми свойствами. В псевдокоде:
Person:
- first_name
- last_name
Тогда ваш реальный код в системе связан только с созданием экземпляров и использованием объектов Person, а не с получением дескрипторов БД или написанием SQL:
p = Person.get(first_name='Joe')
p.last_name = 'Bloggs'
p.save()
В объектно-ориентированном мире вы обнаружите, что ваш код бизнес-логики становится чище (и короче!), Проще в обслуживании и намного более тестируемым.
Конечно, вы правы в том, что это означает, что теперь вам нужно уйти и создать серверную часть базы данных, которая преобразует этот класс Person в одну или несколько таблиц в вашей реляционной базе данных. Вот где использование ORM фреймворка оказывается полезным. В Python люди используют Django и SQLAlchemy. Я позволю другим указать, что люди используют в C # (я не разработчик для C #, но вы отметили свой вопрос OOP, поэтому я собираюсь дать общий ответ, а не конкретный для C #).
Суть в том, что платформа ORM помещает весь доступ к БД в единый набор классов в коде, так что доступ к БД, конфигурация и пулы обрабатываются в одном месте ... нет необходимости создавать их экземпляры во всем приложении. То, что вы используете «там, где вам это нужно» - это объект модели.
Конечно, если ваше приложение очень простое и вам нужен только необработанный дескриптор БД, тогда я рекомендую подход внедрения зависимостей, который перечислили другие.
Надеюсь, это поможет.