Шаблон проектирования для одной и той же сущности на разных уровнях доступа - PullRequest
2 голосов
/ 27 августа 2011

У меня возникли проблемы с поиском подходящего шаблона проектирования для следующей ситуации:

Я программирую MVC с помощью PHP-Activerecord и пользовательской инфраструктуры в корпоративной среде с SOA на основе SOAP.Теперь я пытаюсь получить доступ и / или сохранить в основном одну и ту же сущность на разных уровнях доступа, в зависимости от ситуации.Чтобы быть немного более конкретным, я выберу пример:

В нашей системе есть сущность "Член".Теперь один из способов получить доступ к этому члену - через веб-сервис SOAP, для которого я написал рефератор:

class Member extends ServiceAbstractor {}

Pro: прямой доступ к данным (у меня нет другого способа напрямую связаться с производственной базой данных)).

Con: Довольно медленно, и я не могу легко сделать что-то вроде "JOIN" с другими объектами или "SELECT LIKE '% member1%'" из-за архитектуры, которую я не могу изменить.

Другой способ - получить доступ к той же сущности через более старую репликацию базы данных.Для этого я бы использовал следующий синтаксис:

class Member extends ActiveRecord\Model { /* Connection 1 */ }

Pro: невероятно быстро, и я могу делать все изящные вещи, описанные выше, для фильтрации, создания отчетов и агрегирования данных члена с помощью SQL.

Con: только для чтения, данные немного старше (но на самом деле это не имеет значения для большинства приложений).

Иногда мне даже нужно хранить дополнительные метаданные на члене, например, кто-то что-то изменил, например.

Для этого я бы использовал локальную базу данных MySQL, также с ActiveRecord, но с другим подключением:

class Member extends ActiveRecord\Model { /* Connection 2 */ }

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

Возможный вариант использования: получить идентификатор члена путем частичного поиска имени из копии базы данных (SELECT LIKE), а затем получить«реальный» член веб-службы, обновите его чем-нибудь, а затем сохраните редактор и последние изменения для этого члена в моей локальной базе данных.

Теперь я мог бы назвать соответствующие классы как-то вроде «Member», «MemberCopy» и «MemberMeta» (?), Но это оставляет меня немного неудовлетворенным, так как мне кажется, что я говорю об одной и той же сущности здесь.

Есть ли у кого-нибудь похожие проблемы и / или советы по именованию или шаблонам проектирования для этой проблемы?

1 Ответ

2 голосов
/ 29 августа 2011

Как насчет использования логического простого и простого класса Member (не как объекта сущности) и трех различных классов DAO (один для WS, один для вашей реплицированной БД и оставшийся для вашей локальной БД), которые все принимают как ввод и возврат логических Member объектов?

...