Стратегии для вызывающего абонента решить соединение данных

Question

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

Звоны не хотят управлять строками соединения конкретно, а имена соединений в форме перечисления, который можно решить для строк соединения в уровне данных и по уровню данных.

В настоящее время все классы данных и логики статичны с внутренними данными, а логика общеизвестна.

Каковы некоторые хорошие стратегии, чтобы получить ключ от вызывающего абонента вплоть до методов в классах данных с учетом таких вещей, как использование API, производительность, безопасность потока / абонент и т. Д.

Два очевидных варианта:

1. Добавьте ключ соединения в качестве параметра ко всем методам. Yuck - не произойдет, а в том числе для полноты.

2. Измените логику и классы данных на классы экземпляров и передайте ключ в конструкторах для любого метода участника для использования. Там не будет никаких изменений подписи метода, но существенно нарушение изменения в том, как называется API.

Какие еще есть варианты?

Answer 1

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

Я думаю, что если вы создаете класс обертки на стороне клиента для доступа к Сервису, вы можете ограничить, сколько изменений на стороне клиента вам понадобится. Для самой службы, я думаю, вы действительно будете застрять, передавая соединение в качестве параметра каждый раз просто потому, что альтернативы там довольно сложные.