Шаблон проектирования для одного и того же объекта на разных уровнях доступа

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

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

В нашей системе есть объект «Член». Теперь один из способов получить доступ к этому члену — через веб-службу SOAP, для которой я написал абстрактор:

class Member extends ServiceAbstractor {}

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

Против: довольно медленно, и я не могу легко выполнять такие действия, как «JOIN» с другими объектами или «SELECT LIKE '%member1%'» из-за архитектуры, которую я не могу изменить.

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

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

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

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

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

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

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

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

Возможный вариант использования: получить идентификатор участника с помощью поиска по частичному имени из копии базы данных (ВЫБРАТЬ НРАВИТСЯ), затем получить «настоящего» члена из веб-службы, обновить его чем-то, а затем сохранить редактор и последние изменения для этого члена в моем локальная база данных.

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

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


person endymi0n    schedule 26.08.2011    source источник


Ответы (1)


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

person Marius Burz    schedule 28.08.2011
comment
+1 ваша проблема здесь не связана с моделью (она остается неизменной независимо от источника), она связана с постоянством. DAO как раз для этого и существует. Модель не должна заботиться о постоянстве (и, например, не должна расширять класс, связанный с постоянством, например ActiveRecord\Model). - person Matthieu Napoli; 31.08.2011