Это нарушение Концептуальной Целостности?

Question

Я создаю приложение с несколькими Connector классами, которые взаимодействуют с различными хранилищами данных. Например, см. Мой предыдущий вопрос здесь . В любом случае, как и в моем примере, почти все эти источники данных требуют больших затрат времени при доступе, поэтому каждый Connector поддерживает кэш для ограничения доступа. Для каждого хранилища данных существует IDataSource, который выбирает данные, и Connector, который кэширует. Доступ к Connector осуществляется путем передачи IDataSource фабричному методу в моем классе AppFactory.

К сожалению, есть ровно 1 Connector, который не подходит этой модели. Бункер Active Directory достаточно быстр, чтобы не нуждаться в кеше, поэтому нет необходимости в ActiveDirectoryConnector, и в моем классе AppFactory не было бы фабричного метода. Как я уже говорил ранее, в КАЖДОМ другом случае данные запрашиваются у объекта Connector, который можно получить только при вызове метода AppFactory с параметром IDataSource.

Насколько я могу судить, у меня есть варианты иметь небольшой ActiveDirectoryConnector объект, который просто перенаправляет запросы прямо на IActiveDirectoryDataSource, или вообще не иметь ActiveDirectoryConnector. В первом случае я поддерживаю концептуальную целостность с остальными моими Connector, но у меня бесполезный уровень косвенности. В последнем я жертвую концептуальной целостностью ради непосредственности. Какое меньшее зло?

Answer 1

Я бы сказал, чтобы сохранить вашу модель на месте и не вводить сложность обработки специального случая.Вполне разумно иметь Connector, который просто перенаправляет запрос к возможному источнику данных.Вы не наклоняетесь назад, здесь нет ничего фундаментального для метафоры Connector, которая требует наличия кеша.Кэш - это просто оптимизация производительности, и концепция Connector представляется полезным уровнем абстракции, который позволяет вам вводить кэш (или другую обработку) при необходимости.

Концептуально это несколько похоже на практикудоступ к данным члена для объекта с помощью методов доступа вместо непосредственного использования переменной члена, что многими считается лучшей практикой.Причина этого аналогична: если вы добавите уровень косвенности между клиентом и данными, это позволит вам ввести дополнительную обработку или оптимизацию в будущем, когда к этим данным потребуется доступ.