SeVaТебе здесь не раз объясняли, что в БД объекты не хранятся.

Есть паттерн проектирования Memento - хранитель. Он позволяет отчуждать состояние объекта Originator в объект Memento и помещать его в БД для последующего восстановления состояния исходного объекта Originator. Объект Originator не хранится в БД. Там хранится объект Memento или, если угодно, его копия.

Современные СУБД и API позволяют сосредодочиться на проектировании класса Originator. Класс Memento и соответственно тип записей в таблице БД можно получить почти автоматически из спецификации класса Originator. Механизмы получения объекта Memento из объекта Originator, сохранения его в БД, и обратная процедура реализованы на уровне библиотек, так что проектировщик может отождествлять классы Memento и Originator даже на очень низком уровне абстракции. В данном случае автор опустился ниже этого уровня.

SeVamcureenab, непонятно, но здорово!!!Использование паттерна Momento в подобном контексте я нигде не видел.Какие механизмы, какие API, какие обратные процедуры?Если они тождественны, то зачем нужны эти усложнения?С нетерпением жду продолжения.

Не Momento, Memento, от memory (или наоборот).

Механизмы системы проектирования. Тот же самый MS Visio в UML моделях позволяет тэгировать атрибуты класса приложения (класс Originator в паттерне Memento) признаком persistent, так что генератору схемы БД ясно, какие таблицы и поля (класс Memento в одноимённом паттерне) нужно унаследовать из диаграммы статической структуры и нет надобности моделировать БД руками.

API для доступа к БД, который обеспечивает постоянство (persistence) объекта, т.е. сохранение состояния объекта в БД в процессе сброса кэш и восстановление этого состояния из БД в кэше в процессе разъименовывания объектной ссылки.

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

Область молодая, потому косяков вней встречается изрядное количество, сособенно при попытках скрестить бульдога с носорогом.
Чтобы от запросов не было дурно, СУБД должна поддерживать объектное расширение SQL. Проектировать классы нужно с учётом возможностей платформы. И т.д. и т.п. Скажем так, от повсеместного применения этого подхода в коммерческих приложениях БД я пока воздержусь. Для разработки экранных форм объектные навороты явно лишние (кроме тех объектов-компонентов, что встроены в среду разработки/выполнения). В приложениях со сложной пакетной обработкой данных они могут быть полезными, хотя бы для правильного кэширования данных.

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


Полагаю, тут речь идёт о разделении класса спецификации и класса реализации. Чтобы объект оставался целостным его методы должны работать одинаково независимо от места развёртывания этого объекта. В идеальном случае класс реализуется только в одном компоненте системы, поэтому работает одинаково во всех её приложениях.

Усложнять классы постоянных объектов нет смысла. Как правило такие классы моделируют сущности, а сущности по определению не имеют поведения. Поведение определяют классы-агенты, которые реализуют бизнес-правила и службы системы.

Alexey Kudinov Роман ДынникSOA - взаимодействие. MDA - разработка приложений, управляемых моделью. И да и нет. В случае MDA разработка идет "от модели", в случае SOA [в значительной части] "от сервисов". Т.е. SOA - это взаимодействие конечно, но взаимодействие весьма значительно влияющее на архитектуру приложения.


Так SOA, это и есть архитектура, точнее принцип построения. Только SOA это архитектура самой системы, а MDA архитектура разработки системы.