Предполжим есть сущность, которая по бизнес логике должна сохраняться в трех базах. В 1С, в галактике и в нашей базе к примеру. Бизнес логику не поменять. Для создания такой сущности следует использовать фабрику. Но как быть с обновлением и удалением?

Здравствуйте, Gattaka, Вы писали:

G>Предполжим есть сущность, которая по бизнес логике должна сохраняться в трех базах. В 1С, в галактике и в нашей базе к примеру
Во всех трех одновременно и безусловно? Или либо в одной, либо в другой, либо в третьей в зависимости от некоторых условий?

G>Для создания такой сущности следует использовать фабрику.
Почему? Какие особенности реализации экземпляров сущности будут скрываться фабрикой?

G>Но как быть с обновлением и удалением?
Наверное так же как и с сохранением... нет?

Уточни какое фабрика имеет отношение к требованию "должна сохраняться в трех базах"?

Здравствуйте, stomsky, Вы писали:

S>Во всех трех одновременно и безусловно? Или либо в одной, либо в другой, либо в третьей в зависимости от некоторых условий?
Давай рассмотрим оба варианта.

G>>Для создания такой сущности следует использовать фабрику.
S>Почему? Какие особенности реализации экземпляров сущности будут скрываться фабрикой?
Логика по созданию доменного объекта в нескольких местах. Если добавится еще одно место хранения мы только в фабрике это поправим и все. Не будем по всему коду вычищать.

G>>Но как быть с обновлением и удалением?
S>Наверное так же как и с сохранением... нет?
Ну вот об этом и вопрос. Если создание сущности абстрагируется особым паттерном — фабрика, то почему нет паттерна для обновления или удаления?

S>Уточни какое фабрика имеет отношение к требованию "должна сохраняться в трех базах"?
см. выше.

Здравствуйте, Gattaka, Вы писали:

G>>>Для создания такой сущности следует использовать фабрику.
S>>Почему? Какие особенности реализации экземпляров сущности будут скрываться фабрикой?
G>Логика по созданию доменного объекта в нескольких местах. Если добавится еще одно место хранения мы только в фабрике это поправим и все. Не будем по всему коду вычищать.
Я правильно понял, у тебя фабрика не только создает объект сущности, но при этом еще сама же отвечает за его сохранение в базах данных 1С, Галактики и пр.? Мне кажется, это не совсем удачное решение. У паттерна фабрика изначально немного другое предназначение.
Может быть функционал создания, изменения, удаления сущности вынести в отдельный класс (не знаю как его назвать по-научному, предлагаю условное название "EntityDataAccessor"), а фабрика (если она вообще будет нужна после такого рефакторинга) будет создавать экземпляры этого EntityDataAccessor-а?
Ну или, если твоя фабрика это нечто типа:

public class EntityFactory
{
  public Entity CreateEntity()
  {
    ...
  }
}

То просто перестань рассматривать ее паттерн фабрика, переименовав и расширив этот класс так (см.выделенное жирным):

public class EntityDataAccessor
{
  public Entity CreateEntity()
  {
    ...
  }
  public void Update(Entity entity)
  {
    ...
  }
  public void Delete(Entity entity)
  {
    ...
  }
}

Здравствуйте, Gattaka, Вы писали:

S>>Во всех трех одновременно и безусловно? Или либо в одной, либо в другой, либо в третьей в зависимости от некоторых условий?
G>Давай рассмотрим оба варианта.
Это довольно разные варианты. Во втором случае просто сохраняешь и всё. В первом случае... а что если в двух базах сохранилось, а в третей — constraint какой-нибудь упал или место кончилось? Откатывать всё или надеяться на авось? Нужен поди какой-нибудь 2PC. Или сделать одну из БД "главной", работа будет только с главной БД, а остальные две просто синхронизируются в фоне.

G>>>Но как быть с обновлением и удалением?
S>>Наверное так же как и с сохранением... нет?
G>Ну вот об этом и вопрос. Если создание сущности абстрагируется особым паттерном — фабрика, то почему нет паттерна для обновления или удаления?
Ты путаешь. Фабрика — для создания инстансов класса. А бд это копирование данных инстанса из/в внешнего хранилища — persistence.
Для доступа к базам данных есть паттерны DAO, repository, ORM. Например:

interface MyEntityDao
{
    void insert(MyEntity entity);
    void update(MyEntity entity);
    void delete(MyEntity entity);
}
...
class GalaxyMyEntityDao implements MyEntityDao
{
    @Override void insert(MyEntity entity) {galaxyConnection.doInsert(...entity...);}
...
}
class JdbcMyEntityDao implements MyEntityDao
{
    @Override void insert(MyEntity entity) {jdbc.execute("INSERT INTO MY_ENTITY_TABLE(...)...", ...entity...);}
...
}
...

И тут же можно размножать:

class MultipleStoreMyEntityDao implements MyEntityDao
{
    GalaxyMyEntityDao galaxy;
    JdbcMyEntityDao jdbc;
    OneCMyEntityDao oneC;
    @Override void insert(MyEntity entity)
    {
        // надо ещё добавить правильную обработку исключений.
        galaxy.insert(entity);
        jdbc.insert(entity);
        oneC.insert(entity);
    }
}

Здравствуйте, Gattaka, Вы писали:

G>Предполжим есть сущность, которая по бизнес логике должна сохраняться в трех базах. В 1С, в галактике и в нашей базе к примеру. Бизнес логику не поменять. Для создания такой сущности следует использовать фабрику. Но как быть с обновлением и удалением?

Для удаления сущность создавать не нужно, достаточно какого-то её идентификатора (имени). Передал его репозиторию сущностей, то всё удалил. Обновлением занимается сама сущность, ей больше всех известно что именно надо обновлять.

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