Правильность 3-х уровневой архитектуры

Question

У меня есть проект, реализованный в (некорректной) 3-уровневой архитектуре. Моя работа заключается в том, чтобы сделать его более общим, чтобы было легко добавить новую базу данных в проект.

Конкретный: для базы данных SQL существует databaseFacade, и мне нужно сделать его более универсальным, чтобы мы могли очень легко добавить несколько баз данных. В этом случае запись в файл CSV.

Моя идея на уровне базы данных состояла в том, чтобы создать интерфейс, в котором определены все методы. Затем наличие фасада базы данных (в зависимости от того, что вы хотите использовать), реализующего этот интерфейс, чтобы он стал более универсальным. Тогда у меня есть какой-то класс DBmanager. Этот класс DBmanager будет считывать файл конфигурации, чтобы он знал, какую базу данных использовать. На основе этой информации он создаст экземпляр интерфейса и вернет его на прикладной уровень.

Однако здесь я не знаю, прав ли я. Уровень приложения теперь имеет класс DBmanager (где все правильно инкапсулировано, только один метод является общедоступным для возврата фасада), и после этого DBfacade.

Есть мысли о правильности этого? Так как у меня есть сомнения.

Answer 1

Я видел, как система PHP ( Moodle ) использует почти точно этот шаблон, и он отлично работает.Все, что происходит, это то, что тип БД указывается в качестве переменной конфигурации, а конкретный класс доступа к БД создается как объект глобального менеджера БД, предоставляя методы фасада, например, get_records (), который возвращает стандартизированный массив объектов строк.Можно спорить, назовете ли вы этот фасад или адаптер, но это вряд ли беспокоит.

Я бы сказал, пойти на это с вашим текущим планом.Похоже, вы правильно расцепили слои и поняли назначение шаблонов.Кроме того, то, как ваши низкоуровневые (БД) и высокоуровневые (прикладные контроллеры) компоненты зависят от одного интерфейса фасада БД в середине, является хорошим примером инверсии зависимостей , так что бонусные очки за это!:)

Answer 2

Это правильный подход. Одна небольшая ошибка в том, что ваш DBManager фактически следует шаблону Factory и поэтому должен называться DatabaseFacadeFactory, при условии, что ваш класс фасада называется DatabaseFacade.

Когда вы освоитесь с Java, ознакомьтесь с Spring . Он предоставляет множество инструментов и методов, которые автоматически обрабатывают такие ситуации и устраняют необходимость в значительной части стандартного кода. Для получения дополнительной информации см. внедрение-зависимости .

Answer 3

Мне это кажется законным. Я еще не являюсь экспертом в области архитектуры программного обеспечения, но ваше описание описывает схожую концепцию по сравнению с тем, как был разработан JDBC.