В своем проекте использую toplink. Используются автогенеренные сущности по схеме базы данных.
Проект в начальном состоянии и поэтому структура базы данных довольно часто меняется под нужды различных приложений.
Но та часть структуры, которая необходимо мне остается неизменной. Тем не менее, после изменения структуры базы генеренные сущности уже не могут описать ее. Следовательно требуется их перегенерация. Таким образом, мне нужно абстрагироваться от этих сущностей, работать не напрямую через них, а через адаптер. Toplink использую недавно, поэтому не знаю подводных камней.
Не могли бы вы мне посоветовать какой-то стандартный подход для решения этой проблемы?
Так же приветствуются отсылки к литературе.
Здравствуйте, kermed, Вы писали:
K>В своем проекте использую toplink. Используются автогенеренные сущности по схеме базы данных. K>Проект в начальном состоянии и поэтому структура базы данных довольно часто меняется под нужды различных приложений. K>Но та часть структуры, которая необходимо мне остается неизменной. Тем не менее, после изменения структуры базы генеренные сущности уже не могут описать ее. Следовательно требуется их перегенерация. Таким образом, мне нужно абстрагироваться от этих сущностей, работать не напрямую через них, а через адаптер. Toplink использую недавно, поэтому не знаю подводных камней.
K>Не могли бы вы мне посоветовать какой-то стандартный подход для решения этой проблемы? K>Так же приветствуются отсылки к литературе.
1) Сгенерили сущности по БД и все — дальше руками, никаких перегенерить.
2) Те сущности которые не нужны — удалить. И не будет проблем с их изменением.
3) Топлинк сам себе адаптер но абстрагирует он от БД — в определенных границах конечно.
GIV>1) Сгенерили сущности по БД и все — дальше руками, никаких перегенерить. GIV>2) Те сущности которые не нужны — удалить. И не будет проблем с их изменением. GIV>3) Топлинк сам себе адаптер но абстрагирует он от БД — в определенных границах конечно.
Я наверное неточно объяснил, чего я хочу.
Весь вопрос сводится к этому:
Можно ли наделять сущности управляющей логикой, или для этого целесообразно использовать классы-адаптеры?
Здравствуйте, kermed, Вы писали:
K>Можно ли наделять сущности управляющей логикой, или для этого целесообразно использовать классы-адаптеры?
Вам стоит терминологию хотя бы подтянуть. Что такое "управляющая логика"? Управляющая чем? Может имелось ввиду domain logic или business logic? Адаптер это сущность, которая позволяет совместить различные не совмещеные подсистемы. Например подружить два разных API.
К примеру, был себе такой ORM Toplink. И была такая себе спецификация JPA. Так вот чтобы использовать Toplink через JPA API существуют некие классы-адаптеры. Это пример адаптера. И какое отошение адептеры имеют к изначальному вопорсу не понятно вообще.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, kermed, Вы писали:
K>>Можно ли наделять сущности управляющей логикой, или для этого целесообразно использовать классы-адаптеры? B>Вам стоит терминологию хотя бы подтянуть. Что такое "управляющая логика"? Управляющая чем? Может имелось ввиду domain logic или business logic? Адаптер это сущность, которая позволяет совместить различные не совмещеные подсистемы. Например подружить два разных API.
B>К примеру, был себе такой ORM Toplink. И была такая себе спецификация JPA. Так вот чтобы использовать Toplink через JPA API существуют некие классы-адаптеры. Это пример адаптера. И какое отошение адептеры имеют к изначальному вопорсу не понятно вообще.
B>Если вас просто интересует типовая архитектура приложений, то вот здесь хорошо описано: B>http://rsdn.ru/forum/design/2097068.aspx
Спасибо, но я знаю что такое адаптер и для чего он используется. Вопрос был про бизнес-логику. И да, мне интересен архитектурный подход для работы с toplink.
Здравствуйте, kermed, Вы писали:
K>Спасибо, но я знаю что такое адаптер и для чего он используется.
Тогда что к чему адаптируем?
K>Вопрос был про бизнес-логику. И да, мне интересен архитектурный подход для работы с toplink.
Abstract DAO как и для любого другого persistence
Здравствуйте, Blazkowicz, Вы писали:
B>Тогда что к чему адаптируем?
Имелась ввиду некая прослойка между сущностью и классами приложения. Хотя да, наверное терминология выбрана неверно.
B>Abstract DAO как и для любого другого persistence
K>Проект в начальном состоянии и поэтому структура базы данных довольно часто меняется под нужды различных приложений. K>Но та часть структуры, которая необходимо мне остается неизменной. Тем не менее, после изменения структуры базы генеренные сущности уже не могут описать ее. Следовательно требуется их перегенерация. Таким образом, мне нужно абстрагироваться от этих сущностей, работать не напрямую через них, а через адаптер.
Если честно, я не очень понял, чем тут адаптер может помочь... Если у какой-то таблицы PK был из одного поля, а стал вдруг составным — то как адаптер такое изменение съадаптирует? Или два поля добавилось, а третьего не стало...
Или же изменения в датабазе сводятся к тому, что был CHAR2(10), а стал VARCHAR2(20)?
Здравствуйте, cvoronin, Вы писали:
K>>Проект в начальном состоянии и поэтому структура базы данных довольно часто меняется под нужды различных приложений. K>>Но та часть структуры, которая необходимо мне остается неизменной. Тем не менее, после изменения структуры базы генеренные сущности уже не могут описать ее. Следовательно требуется их перегенерация. Таким образом, мне нужно абстрагироваться от этих сущностей, работать не напрямую через них, а через адаптер.
C>Если честно, я не очень понял, чем тут адаптер может помочь... Если у какой-то таблицы PK был из одного поля, а стал вдруг составным — то как адаптер такое изменение съадаптирует? Или два поля добавилось, а третьего не стало... C>Или же изменения в датабазе сводятся к тому, что был CHAR2(10), а стал VARCHAR2(20)?
