Стратегии для звонящего, чтобы решить подключение данных - PullRequest
Новая
       1

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

1 голос
/ 22 января 2011

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

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

В настоящее время все классы данных и логики являются статическими с внутренней областью данных и общедоступной логикой.

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

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

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

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

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

1 Ответ

0 голосов
/ 22 января 2011

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

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

...