|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Есть желание научиться правильной организации приложений, работающих с базами данных. Понятно, что универсальных методов нет, но хотелось бы выделить некий базис, с к-го можно начинать. Допустим, есть некая БД. Конкретная СУБД и структура данных не имеет значение. Хотелось бы всю работу с БД организовать через некий набор классов. Конечно, эти классы будут привязаны к базе данных, да и вообще к описываемым бизнес-процессам. Но в то же время наверняка можно выделить общие моменты. Я хотел бы спросить у бывалых людей. Расскажите, как правильно (с Вашей точки зрения) строить классы для доступа к базе данных? Какие общие интерфейсы, методы и поля можно у таких классов? Например, можно сказать, что классы, отображающие хранимые объекты, должны реализовывать интерфейс..ну например IDBObject: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
Вобщем, прошу поделиться опытом. Что и как. :) З.Ы. Может, слишком сумбурно выразился, но надеюсь общий смысл ясен.. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2005, 04:36 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Пример ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2005, 06:29 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
У меня пока дело закончилось тем что в общей таблице "Class" имеются ссылки на таблицу описания метаданных конкретного класса. Дык вот эта самая таблица в идеале мне должна потом дать всё: исходники классов, заготовки методов работы с базой, хэлпы и так сказать сам DDL. При этом я понимаю, что вплотную подобратся к изобретению колеса, но в моём случае была уже готовая система с очередной попыткой запихнуть объекты в РСУБД. При этом всегда существует требование непосредственного доступа стандартными средствами в свойствам объектов. Так что на бесплатную ООСУБД тут не скатишься. Возвращаясь к сути вопроса, я хочу отметить что к удобствам я получил ещё и проблему отсутствия необходимых утилит к моим придуманным звеньям. Т.е возникает вопрос: на сколько все эти трудозатраты потом оправдаются? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.07.2005, 18:48 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
to nik_x Спасибо. Меня правильно поняли. :) Но Ваш пример никак не оперирует объектами, находящимися в базе. Т.е. используя эту библиотеку я жестко привязан к структуре БД, да и к конкретной СУБД - ведь иначе я не смогу написать запрос (и исполнить через эту либу). Мне бы хотелось абстрагироваться от конкретной СУБД и структуры хранимых данных. Т.е. пишем некий Framework, некий набор классов (описывающих бизнес-объекты, а не просто оболочка над соединением!), к-е непосредственно отправляют запросы к СУБД, а в остальном работа приложения происходит лишь в вызовах методов моих классов. Таким образом, написав подобную библиотеку, мне совершенно без разницы, какие таблицы, какие поля и связи - я работаю лишь с нужными мне бизнес-объектами. Дополнительный плюс такого подхода, как мне кажется, - облегчается процесс миграции на другую СУБД (если в этом есть необходимость). Мы просто поменяем набор классов из нашего фреймворка - остальная логика приложения не поменяется. Поэтому мне хотелось бы выработать некий общий подход к созданию такого вот промежуточного слоя для работы с конкретной СУБД. Поделитесь опытом, как лучше организовать такие классы? to Михаил Михайлович Понимаю. Мне приходила подобная мысль. Правда мой вопрос не касается набора таблиц, к-е должны быть в базе - я говорю о клиентской части. Но все же.. Не боитесь тормозов в работе такой системы? Например, (ИМХО!) при вставке нового объекта будет блокироваться куча таблиц. Или другая проблемка - судя по всему, такие "общие", универсальные таблицы будут бОльшего размера, чем в случае, когда таблица отражает лишь один конкретный объект. Т.е. то, что в "классической" реляционной схеме хранится 10-20 таблицами, у Вас будет храниться в 3-4. А чем больше размер таблиц, тем больше нагрузка на сервер. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 00:24 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Pilot Мне бы хотелось абстрагироваться от конкретной СУБД и структуры хранимых данных. Судя по Вашим вопросам, Вы новичок в этой области(извините, если это не так). Зачем замахиваться сразу на "миллион с королевой"?:) Попробуйте сначала создать классы, хотя бы, для одного какого-нибудь сервера, не зацикливаясь на "абстрагировании" и прочих рекламных мульках - Вы же, я надеюсь, не маркетолог, а, в первую очередь, инженер? Pilot Дополнительный плюс такого подхода, как мне кажется, - облегчается процесс миграции на другую СУБД (если в этом есть необходимость). Мы просто поменяем набор классов из нашего фреймворка - остальная логика приложения не поменяется. Зачем менять СУБД? Ни разу такого не встречал(!), кроме тех случаев, когда менялась полностью система. Так что - фтопку! Вместе с остальной рекланой шелухой. Pilot А чем больше размер таблиц, тем больше нагрузка на сервер. Да, Вы новичок. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 01:21 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Да, Вы новичок. Не отрицаю. Но хочу выйти на нормальный уровень. Неужели то, что предложил nik_x - это максимум, что можно и нужно делать? Кроме того, я не занимаюсь "рекламной шелухой" - до этого момента я действительно верил, что это солидные преимущества. :) Тогда как правильно? В каждом обработчике кликов, в каждой ф-ции напрямую использовать SQL-запросы? Или оформлять вызовы SQL-запросов в ф-ции и в отдельные модули? Тогда фактически мы приходим все к тому же варианту с классами - только тут у нас модули. P.S. А по поводу роста нагрузки на сервер при бОльших размерах таблицы.. Не могу согласиться - хоть чуть-чуть, но нагрузка все равно будет бОльше. Согласитесь, время выполнения запроса к 100 мегабайтной таблице будт меньше времени выполнения запроса к 10 гигабайтной таблице. Да, при правильной организации очень и очень ненамного - но все же больше. Но, если не возражаете, спорить на эту тему сейчас не хотелось бы. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 01:49 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Возможно, посоветуете какую-нибудь литературу по моему вопросу? Или существует какой-нибудь хороший Open Source проект, иллюстрирующий правильный подход к проектированию приложений под базы данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 03:01 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Pilot Не отрицаю. Но хочу выйти на нормальный уровень. Неужели то, что предложил nik_x - это максимум, что можно и нужно делать? Кроме того, я не занимаюсь "рекламной шелухой" - до этого момента я действительно верил, что это солидные преимущества. :) Всегда необходимо исходить из задач. Если главная задача, построить систему, которая будет позволять работать на разных СУБД, тогда да, надо так делать. Если же первоочередной ставится задача, построить систему, которая будет эффективно и надежно работать на конкретных бизнес-процессах, и при этом "абстрагируемость от СУБД" будет усложнять выполнение этой задачи, то тогда так не надо делать. Pilot Тогда как правильно? В каждом обработчике кликов, в каждой ф-ции напрямую использовать SQL-запросы? Или оформлять вызовы SQL-запросов в ф-ции и в отдельные модули? Тогда фактически мы приходим все к тому же варианту с классами - только тут у нас модули. Не удивлюсь, что для разных людей будут разные правильные решения. Это сродни писательскому труду. Как правильно написать, например, "Войну и Мир" или хорошую стаью в журнал? Если же конкретно, то, по своему опыту, могу сказать, что на разных этапах своего "программерского" развития принципы "правильности" в макромасштабах постоянно менялись, в стратегическом же плане для меня неизменно два принципа - простота и сопровождаемость. Достигнуть простого и сопровождаемого решения - сложная и, одновременно, интересная инженерная задача. И, "абстрагируемость"(извините, что привязался к этому слову), здесь совершенно ни при чем. (Хотя для маркетологов это "конек":)) Pilot P.S. А по поводу роста нагрузки на сервер при бОльших размерах таблицы.. Не могу согласиться - хоть чуть-чуть, но нагрузка все равно будет бОльше. Согласитесь, время выполнения запроса к 100 мегабайтной таблице будт меньше времени выполнения запроса к 10 гигабайтной таблице. Да, при правильной организации очень и очень ненамного - но все же больше. Но, если не возражаете, спорить на эту тему сейчас не хотелось бы. Возражаю и поспорю:) Сервер работает с ЗАПРОСАМИ - они то его и грузят. Можно запросом к одной маленькой таблице поставить сервер на колени, и наоборот вернуть быстро результат от джойна по нескольким гигабайтным таблицам. В том то и прелесть SQL серверов. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 09:45 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Возможно, мое утверждение покажется слишком банальным, но мне кажется, что проектировать приложение нужно так, как это предлагает средство разработки. Просто Вы себя избавите от массы лишних проблем, не связанных с задачей. К тому же ООП это ведь не цель, а средство. Не стоит его использовать где не попадя. Разумеется, бывают случаи, когда применение объектного подхода упрощает доступ к данным. В этом случае можно использовать proxy-объекты, т.е. объект представляет собой строку DataSet, а свойства объекта - поля этой строки. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 09:52 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
авторЕсть желание научиться правильной организации приложений, работающих с базами данных. Эх, где же наша книжка......... :( авторДопустим, есть некая БД. Конкретная СУБД и структура данных не имеет значение. Хотелось бы всю работу с БД организовать через некий набор классов. Что вы подразумеваете под набором классов для работы с БД ? Доступ к БД? Есть Query, ADOQuery например. Чего не хватает? авторКонечно, эти классы будут привязаны к базе данных, да и вообще к описываемым бизнес-процессам. Но в то же время наверняка можно выделить общие моменты. Ну например какие моменты вы бы выделили? авторЯ хотел бы спросить у бывалых людей. Расскажите, как правильно (с Вашей точки зрения) строить классы для доступа к базе данных? Никак. Нет их, классов :) авторТ.е. пишем некий Framework, некий набор классов (описывающих бизнес-объекты, а не просто оболочка над соединением!), к-е непосредственно отправляют запросы к СУБД, а в остальном работа приложения происходит лишь в вызовах методов моих классов. Таким образом, написав подобную библиотеку, мне совершенно без разницы, какие таблицы, какие поля и связи - я работаю лишь с нужными мне бизнес-объектами. Ну вы приведите пример все же такой работы. авторТогда как правильно? В каждом обработчике кликов, в каждой ф-ции напрямую использовать SQL-запросы? Или оформлять вызовы SQL-запросов в ф-ции и в отдельные модули? Тогда фактически мы приходим все к тому же варианту с классами - только тут у нас модули. Пример, пример приведите того, как вы бы хотели работать, конкретный пример. Пока что непонятно, чего конкретно вы хотите. Каких таких классов. Как только приведете пример, можно будет вам ответить. Иначе можно только посоветовать Bold for Delphi - ищите топик в форуме по Дельфи. А вообще - не с того начинаете, совсем не с того. Не надо заморачиваться на супер-пупер классах, которые будто бы сами все сделают. -- Tygra's -- ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 09:55 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Пример? Хм.. Сейчас мне это тяжеловато сделать.. Ну, только не придирайтесь сильно, допустим, в базе данных есть пользователь (для простоты, пусть храним имя/пароль). Тогда у нас появляется класс User. Приблизительно такой: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
Естественно, это лишь утрированный пример того, чего я добиваюсь. Чувствую, что сейчас я пишу неправильно - вызовы SQL-запросов разбросаны по всему коду. Создается .. хм..ощущение неопрятности что ли. Я стараюсь прийти к единой схеме организации приложений. Пока что не получается. :) Вобщем, спасибо за ответы. Как я понимаю, интересующие меня правила приходят с опытом. Что ж, буду продолжать работать. Думаю, тему можно закрывать. P.S. tygraА вообще - не с того начинаете, совсем не с того. Не надо заморачиваться на супер-пупер классах, которые будто бы сами все сделают. Тогда посоветуйте, на что следует обратить внимание? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 13:11 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Постараюсь дать писчу для размышлений... Сразу оговорюсь... Тут правильно (на мой взгляд) уже было сказано - не понятно нахфига такая задача ? А писча следующая... Я не думаю, что Вы придумали нечто новое. И не думаю, что такие мысли не приходили лет эдак 20 назад в головы программистов. Дык почему ? Неужели никто не сделал "программу века" чтоб удешевить разработку софта ? Все идиоты ? навряд ли... точнее - лично я НЕ ВЕРЮ таким выводам. Вряд ли все кругом идиоты и идут через к терни к звёздам. Из опыта скажу. За универсальность - приходиться платить. Чем ? я так понимаю, что одним из тех плюсов, за которые люди платят. А компы нам дают а) - скорость б) точность... Я так понимаю, что пункт "а" - при универсализме страдает. И думаю не на некий маленьчкий коэфициент, а на ПОРЯДКИ. Почему так - а из жизни. Очень часто, при реализации проектов. Когда и софт и база - заточены под задачу, ан нет... Есть места где минимизируешь временные потери, но увы - всё равно выше не прыгнуть. А Вы ведёте речь об универсализме. И ещё. Вот уменьшение затрат (и по коду и по времени и прочих аспектов) при уходе от абстракции - встречал. Обратно - увы, нет. Кстати вот пример. Очень простой. Лично знаю людей, которые ОПТИМИЗИРОВАЛИ код конкретной задачи нарисованной на яве под тот или иной движок (!). Это с учётом того, что данному языку не год и не два, и даже не пять :) Я бы сказал, что заявленный универсализм данного языка - не состоялся. с уважением (круглый) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 13:19 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
kolobok0Я не думаю, что Вы придумали нечто новое Конечно. Я не сомневаюсь, что это уже проходилось. Поэтому и спросил совета у "проходивших", как лучше (с Вашей точки зрения). Мне хотелось бы определиться стоит ли работать в этом направлении или это тупик. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 13:34 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Pilot kolobok0Я не думаю, что Вы придумали нечто новое Конечно. Я не сомневаюсь, что это уже проходилось. Поэтому и спросил совета у "проходивших", как лучше (с Вашей точки зрения). Мне хотелось бы определиться стоит ли работать в этом направлении или это тупик. Это не тупик, это очень сложный вопрос... Даже такие монстры, как например Оракле выдали CaseDesigner. Продукт не скажу, что очень простой... То, что я предложил... Это попытка абстрагироваться от конкретной СУБД. И в и-нете есть несколько подобных выриантов. Лично у меня это работает на Oracle & FB. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 14:08 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
В Вашем посте выше прозвучало о "...стараюсь прийти к единой схеме организации приложений...". Если позволите - немного своих мыслей на этот счёт... мне каеться, что любая структура распадаеться на следующее... 1) графический слой. это Ваши супер-мега контролы. обработчики от клиента, передача бизнес обьектам контекста управления и т.д. 2) бизнес слой. это совокупность классов полностью закрывающих вашу задачу. ну тут мона говорить бесконечно. но лучше (мне кажеться) взглянуть на книги авторов типа Буча. 3) сервак приложения. Это код "снабжающий" бизнес слой инфой из различных каналов (в том числе и БД) и оперирующий этой инфой. Как правило данный слой имеет выраженный отпечаток "бизнес задачи", но как правило не несёт нагрузку по экземплярности бизнес обьектов. Сюда удачно ложаться различные транзакционные цепочки, задачи в офф лайн режиме и прочии возможности. Примечания... а) как правило между 2 и 3 пунктом - канал передачи данных. б) если ваша задача общаеться с БД, то после принятия решения о "фамилии" движка БД и её возможностей, необходимо поставить вопрос о целесообразности 3 пункта при решении ДАННОЙ КОНКРЕТНОЙ задачи. Вполне возможно, что Вы обойдётесь функционалом встраемого языка при реализации всех потребностей. Пример... В одной из задач, требовалось а) высокая надёжность-целостность данных б) закрытость в) скорость Как решение - использовалась база Btrieve (операционка Novell), при этом механизм транзакционности использовался только при сервисных операциях. Блокировки вообще не использовались. База открывалась монопольно сервером приложения. На момент подьёма NLM происходила проверка данных и целостность базы данных. Бэкап при таком решении делался за 0 минут 0 секунд (вне зависимости от кол-ва данных), при этом срез бэкапа был по всей базе данных. Так же были реализованы службы по автоматическим сервисам (закачка, разархивация данных из вне. адаптация нагрузки и каналов в зависимости от кол-ва клиентов и прочее.) Моментальное формирование отчётов (за 0 минут 0 сек, вне зависимости от обьёма данных) так же было запланировано, но в данную версию не вошло. с уважением (круглый) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 14:13 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Ну тогда вам действительно сюда: Bold for Delphi /Bold for C++. Вторая попытка. -- Tygra\'s -- ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 15:30 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Pilotto nik_x Понимаю. Мне приходила подобная мысль. Правда мой вопрос не касается набора таблиц, к-е должны быть в базе - я говорю о клиентской части. Но все же.. Не боитесь тормозов в работе такой системы? Например, (ИМХО!) при вставке нового объекта будет блокироваться куча таблиц. Или другая проблемка - судя по всему, такие "общие", универсальные таблицы будут бОльшего размера, чем в случае, когда таблица отражает лишь один конкретный объект. Т.е. то, что в "классической" реляционной схеме хранится 10-20 таблицами, у Вас будет храниться в 3-4. А чем больше размер таблиц, тем больше нагрузка на сервер. Это если до конца нормализовать, если мы с Вами вобще об одних вещах говорим :). Но есть ещё юзабилити и конструктивные соображения. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 20:53 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
может я что-то не понимаю, но мне кажется что вам сюда http://]http://hibernate.org/ ... |
|||
:
Нравится:
Не нравится:
|
|||
11.07.2005, 23:31 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
jikezможет я что-то не понимаю, но мне кажется что вам сюда http://]http://hibernate.org/ Интим за деньги не предлагать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2005, 13:55 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Михаил Михайлович Интим за деньги не предлагать. это что шутки такие? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2005, 23:10 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
посмотрите здесь http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html ... |
|||
:
Нравится:
Не нравится:
|
|||
15.07.2005, 11:00 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Благодарю. Буду разбираться.. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.07.2005, 14:14 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
jikez Михаил Михайлович Интим за деньги не предлагать. это что шутки такие? Дык там платно ... |
|||
:
Нравится:
Не нравится:
|
|||
17.07.2005, 19:56 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Guestпосмотрите здесь http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Прочитал и осмыслил. Похоже, это то, что я искал. Еще раз спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.07.2005, 03:42 |
|
Структура классов для доступа к БД?..
|
|||
---|---|---|---|
#18+
Pilot Guestпосмотрите здесь http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html Прочитал и осмыслил. Похоже, это то, что я искал. Еще раз спасибо. Не надо изобретать велосипед. Тема разработки framework для реляционных баз давно обсосана. По крайней мере шишек набито очень много. Hibernate именно поэтому и появился, что работа с базой превратилась в геморрой. Найдите какой-нибудь готовый framework и на нем пишите. Насколько я знаю Hibernate можно скачать. Готовый framework (ADF BC) есть у Oracle, скачать и пользовать для разработки можно даром, правда конечный пользователь должен купить лизенцию на использование. DAO, как и MVC - это только паттерны. В стандартных framework эти паттерны уже реализованы. Даже если надумаете писать сами, посмотрите сначала готовые решения, может быть какие-то подходы оттуда возьмете. К примеру, в классы, описывающие сущности базы данных НЕ вставляют явные описания полей. Вот так не делают: Код: plaintext 1. 2. 3. 4. 5. 6.
Структуру таблицы базы хранят в XML, а класс (Entity), описывающий сущность, вытягивает описание таблицы из XML. Класс Entity может вытянуть описание любой таблицы. Ваш класс User наследует Entity и в свой класс User вы вставляете логику, специфичную для User. А в Entity лежит общая для всех таблиц логика общения с базой (insert, update, delete, select). Насколько я знаю - это общий подход. Мой совет - найдите книжку по Hibernate, там много интересного написано. Во всяком случае там очень внятно описаны проблемы, которые имеются при организации связи Java - реляционная база. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.07.2005, 19:06 |
|
|
start [/forum/topic.php?fid=33&fpage=64&tid=1549581]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
84ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
others: | 273ms |
total: | 470ms |
0 / 0 |