В программе используется иерархическая БД, для хранения данных о датчиках прикрепляемых к пациенту:
Чтобы проще было представить
Программ изначально писалась второпях, и на текущей момент sql запросы раскинуты по всей программе. Сейчас возникла идея создать компонени для работы с данной БД, который позволил бы как минимум абстрагироваться от используемой БД, а как максимум вообще забыть о способе хранения данной иерархии.
Каждая запись бд имеет свой id, а также id родительского элемента (кроме элементов верхнего уровня)
Для удобной работы с данной бд созданы следующие классы:
Соответственно три уровня иерархии представлены классами: Person, Session, Place имеющими общего предка DBRecord. Троеточиями ибозначены поля классов, которые в данном случае не интересны (например для Person это имя, фамилия)
Класс Saver инкапсулирует работу с БД и может быть заменен при переходе на другую БД. Saver может быть дополнен методами для выборки объектов из БД по каким-то другим значениям.
Объекты SessionCollection и PlaceCollection создаются и заполняются объектами при первом обращении к соответствующим полям Sessions и Places классов Person и Session. При добавлении и удалении объектов в этих коллекциях производятся синхронные действия с БД. А каждый объект типа DBRecord имеет метод Save, который сохраняет себя в БД.
Если объекты Session и Place были получены из коллекций SessionCollection и PlaceCollection соответственно, то их поля Person и Session ссылаются на уже существующие объекты. Если же они были получены непосредственно от Saver, то при обращении к данным полям объекты запрашиваются из БД с помощью Saver.
На текущий момент все описанное реализовано, разве что полноценное тестирование сложно устроить. В конечную программу не включено. Код получился достаточно красивым и компактным. Пользоваться достаточно удобно и интуитивно понятно. Единственное что меня беспокоит, а не перемудрил ли я? Ну и может кто предложит что-то лучшее.
Для своего развития конечно неплохо такой велосипедик изобрести. Но скорее всего все что вы будете придумывать уже сделано и даже в 50 раз больше. Кстати, сразу кидается в глаза мега-класс Saver который будет видимо содержать 15 триллионов методов для работы с БД. Разделите этот класс на несколько классов, где каждый класс например предоставляет методы для работы с определенной таблицей.
Ну а вообще, советую посмотреть то что уже есть, например BLToolkit. Не поленитесь, уделите денёк и почитайте документацию, примеры, в общем посмотрите возможности. Вот я недавно написал здесь
Спасибо за подробный ответ, MozgC, Вы писали:
MC>Кстати, сразу кидается в глаза мега-класс Saver который будет видимо содержать 15 триллионов методов для работы с БД. Разделите этот класс на несколько классов, где каждый класс например предоставляет методы для работы с определенной таблицей.
Согласен. В моем конкретном случае методов будет может и не так уж много, но теоретически это минус. В таком случае Saver будет конетейнером для мелких классов.
MC>Ну а вообще, советую посмотреть то что уже есть, например BLToolkit. Не поленитесь, уделите денёк и почитайте документацию, примеры, в общем посмотрите возможности. Вот я недавно написал здесь
в одном месте основные известные мне ссылки относящиеся к BLToolkit, почитайте, будет полезно.
BLToolkit пока посмотрел в общем. В данном случае он может или просто сильно упростить реализацию Saver, либо частично его заменить.
И все таки приведенный нобор классов никак не заменяет ORM. Они друг друга по-моему успешно могут дополнять. Данные класы сильно специализированы под конкретную задачу. ORM разме может учитывать и автоматически развертывать иерархическую структуру БД?
Здравствуйте, netDalek, Вы писали:
D>И все таки приведенный нобор классов никак не заменяет ORM. Они друг друга по-моему успешно могут дополнять.
Ну как вам сказать. ORM разные бывают и пользоваться ими можно тоже по-разному. К примеру BLToolkit предлагает разные пути работы с ним, что на мой взгляд очень правильно. Т.е. при одном сценарии использования — ваши классы и ORM могут дополнять друг друга. При другом — ваши классы в таком виде будут не нужны уже, или может правильнее будет сказать, что проще будет сделать по-другому. Чтобы не теоретизировать, я все-таки советую вам еще лучше почитать про BLT, тогда вы сами сможете представить как его можно и лучше использовать в вашем проекте. Как минимум — он дает еще более высокоуровневую обертку над ADO.NET и автоматический маппинг. Это как минимум.
D>ORM разме может учитывать и автоматически развертывать иерархическую структуру БД?
Ну как сказать автоматически... Если немного помочь (т.е. это прописывается либо в конфиг. файле, либо атрибутами, либо еще есть способы) — то может.
По поводу вашего изначального вопроса:
Вроде не перемудрили. Основной момент для холивара — это наличие персистент-методов в классах сущностей и их наследование от общих Db-классов (типа DbRecord). Многие считают что классы сущностей должны быть абсолютно абстрагированы от работы с БД, т.е. что методов типа Save() (даже делегирующих сохранение другим классам) быть не должно. Основные причины такого мнения: классы сущностей можно использовать в разных проектах/предметных областях, ну и что если класс содержит методы для работы с БД — то типа он слишком много делает, слишком нагружен, и что этим должны заниматься отдельные классы — сервисы. Но это холиварная тема.
Я считаю что самое главное — чтобы ваша работа как программиста была максимально удобной, чтобы можно было автоматизировать какие-то простые рутинные вещи, и чтобы поддерживать (расширять, менять, рефакторить) всю эту кухню потом было проще. Если эти условия выполняются — отлично. Если можно что-то улучшить — то нужно постараться улучшить.
Ну и последнее — я рекомендую все-таки не изобретать велосипед, а сразу посмотреть на самые современные подходы в работе с БД (т.е. в частности на различные ORM). Иначе вы будете развивать этот свой велосипед, который на практике будет отставать от ведущих технологий/подходов/фреймворков на 5-10 лет. Я например сделал себе простенькую обертку над ADO.NET (типа как DbManager в BLToolkit), сделал средства помогающие облегчить ручной мэппинг и т.д. — а потом увидел что все это было (только еще круче) в том же BLToolkit уже лет 5-7 назад , и что например ручной мэппинг — это зачастую трата времени программиста и уже давно есть средства которые это автоматизируют, а я до сих пор писал код маппинга на полстраницы.
Посмотрел BLToolkit, согласен в вами, классная штука и не маленькая.
MC>По поводу вашего изначального вопроса: MC>Вроде не перемудрили. Основной момент для холивара — это наличие персистент-методов в классах сущностей и их наследование от общих Db-классов (типа DbRecord). Многие считают что классы сущностей должны быть абсолютно абстрагированы от работы с БД, т.е. что методов типа Save() (даже делегирующих сохранение другим классам) быть не должно. Основные причины такого мнения: классы сущностей можно использовать в разных проектах/предметных областях, ну и что если класс содержит методы для работы с БД — то типа он слишком много делает, слишком нагружен, и что этим должны заниматься отдельные классы — сервисы. Но это холиварная тема.
Да, есть здравое зерно в таком подходе, можно сделать extension methods
D>>ORM разме может учитывать и автоматически развертывать иерархическую структуру БД? MC>Ну как сказать автоматически... Если немного помочь (т.е. это прописывается либо в конфиг. файле, либо атрибутами, либо еще есть способы) — то может.
Да тут самое веселье, знания sql начинают хромать
MC>Я считаю что самое главное — чтобы ваша работа как программиста была максимально удобной, чтобы можно было автоматизировать какие-то простые рутинные вещи, и чтобы поддерживать (расширять, менять, рефакторить) всю эту кухню потом было проще. Если эти условия выполняются — отлично. Если можно что-то улучшить — то нужно постараться улучшить.
Да я тоже так считаю, просто иногда узнаешь выполняются ли условия поздновато, в тот момент, когда начинешь расширять, менять, рефакторить.
В общем буду изобретать с BLToolkit. Коллекции думаю можно убрать, хватит IList. Методы добавления и удаления перевести к родительким классам, которые также можно сделать в виде extension. А вот как поступить с иерархией (т.е. на сколько использовать возможности bltoolkit) пока не знаю
, и что например ручной мэппинг — это зачастую трата времени программиста и уже давно есть средства которые это автоматизируют, а я до сих пор писал код маппинга на полстраницы.
