2NetFly
-
Бизнес логика и данные (активная запись, ORM и т.д.)
В соседних темах яро обсуждают реализацию представления и контроллера, а я бы хотел поговорить о реализации модели, а точнее реализации слоя источника данных и его взаимодействии с классами домена.
Во всех своих проектах я использую гибрид паттерна активная запись и ORM. У меня существует класс, реализующий маппинг для единичной таблицы (без внешних связей) с CRUD методами, конфигурирующийся при помощи xml схемы. Данный класс наследуется классами домена и в большинстве случаев этого достаточно.
Однако, если необходимо расширить функциональность CRUD методов, либо добавить дополнительные методы, работающие с БД, приходится реализовывать их в конечном классе домена, что не есть очень хорошо. Напрашивается решение - вынести работу с БД в отдельный слой и пользоваться методами классов этого слоя в классах домена. Т.е. в конечном классе CRUD методы будут делегировать методам прослойки и если понадобится реализовать дополнительную функциональности, изменениям подвергнется только класс прослойки.
Кто что может сказать по этому вопросу? Насколько оправданно создание дополнительного слоя? Может есть какие-то стандартные паттерны для решения подобных задач? Обратился к Фаулеру, вроде бы описываемое мной решение называется Table Gateway, но почему-то его рекомендуется использовать с сценарием транзакции, а не с моделью предметной области.
-~{}~ 17.05.05 21:14:
И в продолжение темы. Небольшой пример (стандартный): музыкальный архив. Для простоты две сущности: композиция и альбом, данные хранятся в разных таблицах (album, song). Два варианта реализации (пишу на перле, думаю всем понятно будет) добавления композиции.
Вариант первый
Вариант второй
И первый и второй варианты используют два паттерна: сценарий транзакций и активная запись. Первый вариант мне кажется более гибким, но менее правильным с точки зрения ООП. Какие мысли по этому вопросу и кто чем пользуется?
В соседних темах яро обсуждают реализацию представления и контроллера, а я бы хотел поговорить о реализации модели, а точнее реализации слоя источника данных и его взаимодействии с классами домена.
Во всех своих проектах я использую гибрид паттерна активная запись и ORM. У меня существует класс, реализующий маппинг для единичной таблицы (без внешних связей) с CRUD методами, конфигурирующийся при помощи xml схемы. Данный класс наследуется классами домена и в большинстве случаев этого достаточно.
Однако, если необходимо расширить функциональность CRUD методов, либо добавить дополнительные методы, работающие с БД, приходится реализовывать их в конечном классе домена, что не есть очень хорошо. Напрашивается решение - вынести работу с БД в отдельный слой и пользоваться методами классов этого слоя в классах домена. Т.е. в конечном классе CRUD методы будут делегировать методам прослойки и если понадобится реализовать дополнительную функциональности, изменениям подвергнется только класс прослойки.
Кто что может сказать по этому вопросу? Насколько оправданно создание дополнительного слоя? Может есть какие-то стандартные паттерны для решения подобных задач? Обратился к Фаулеру, вроде бы описываемое мной решение называется Table Gateway, но почему-то его рекомендуется использовать с сценарием транзакции, а не с моделью предметной области.
-~{}~ 17.05.05 21:14:
И в продолжение темы. Небольшой пример (стандартный): музыкальный архив. Для простоты две сущности: композиция и альбом, данные хранятся в разных таблицах (album, song). Два варианта реализации (пишу на перле, думаю всем понятно будет) добавления композиции.
Вариант первый
Код:
my $album = Album->new($request->getParam("artist_id"));
if (!$album) {
$self->error("Invalid album");
return 0;
}
my $song = Song->new();
$song->setAlbum($album->getId());
$song->setTitle($request->getParam("song_title"));
$song->setLength(...);
$song->save();
Код:
my $album = Album->new($request->getParam("artist_id"));
...
$song->setTitle($request->getParam("song_title"));
$song->setLength(...);
$album->addSong($song);
![[sid]](https://secure.gravatar.com/avatar/c51853b199f011af6ff7bfdc5973af53?s=96){kind=avatar}
