Появилась задача по написанию программы, создание которой может растянуться на годы и вестись разными людьми.
Я склоняюсь к использованию BLT при общении с базой, но возникает вопрос, как лучше реализовывать справочники, которые могут быть пополняемыми и должны храниться в БД. Некоторые из них могут быть иерархическими, некоторые линейными.
Стандартные решения известны, но вопрос какое лучше подходит под BLT, как лучше организовать хранение, иерархию классов? Как описывать в классах поля-ссылки на элементы справочника, чтобы не было потерь памяти?
хотя ближе ему легкая модель, но жирную тоже можно сделать.
еще рекомендую почитать вики, там достаточно много всего полезного, есть некоторые рекомендации, местами грабли описаты (про те же возможные утечки памяти).
Здравствуйте, ili, Вы писали:
ili>вообще BLT не навязывает вам никаких решений — как вам удобно, так и делайте. ili>это фреймворк для фреймворков, так что что хотите — то и воротите
я потому к нему и склоняюсь. Но приходиться трудно при отсутствии внятной документации.
Вики я прочел, но вики есть вики, там описано лишь общие какие-то положения и распространенные варианты использования.
Вот, например, как работает атрибут RelationAttribute? Кто ответственен за удаление дочернего элемента при удалении его из списка? А кто должен его записывать при добавлении его в список? Будет он записан при записи объекта-родителя или нет?
Или, предположим, есть 5 типов объектов, каждый из которых ссылается на один и тот же справочник? Это тоже RelationAttribute или нечто другое или надо руками управляющий класс писать?
AB>Появилась задача по написанию программы, создание которой может растянуться на годы и вестись разными людьми. AB>Я склоняюсь к использованию BLT при общении с базой, но возникает вопрос, как лучше реализовывать справочники, которые могут быть пополняемыми и должны храниться в БД. Некоторые из них могут быть иерархическими, некоторые линейными. AB>Стандартные решения известны, но вопрос какое лучше подходит под BLT, как лучше организовать хранение, иерархию классов?
А можно подробнее о стандартных решениях или ссылки...
AB>Как описывать в классах поля-ссылки на элементы справочника, чтобы не было потерь памяти?
ComplexMapping. Но с этим как-то всё хитро...
AB>Может у кого был такой опыт, поделитесь.
BLT это маппер. Использовать его для общения с базой в простых случаях можно, но шаг в сторону и приходится что-то дописывать. Хотя, надо признаться, это совсем не сложно.
зы. Если у вас двухзвенка, возможно проще будет взять EF или Hibernate.
Здравствуйте, AngeL B., Вы писали:
AB>Вот, например, как работает атрибут RelationAttribute?
из вики:
Важно: декларативное определение отношений не приводит к автоматической выборке иерархий объектов, так же оно никак не влияет на генеразию CRUD запросов. Если рассмотреть приведенный выше пример, то по факту оно позволяет не указывать релэйшены для резалтсетов:
т.е. RelationAttribute пользуется только в MappingSchema.MapResultSets
AB>Кто ответственен за удаление дочернего элемента при удалении его из списка? А кто должен его записывать при добавлении его в список? Будет он записан при записи объекта-родителя или нет?
а вот за все это отвечаете вы.
AB>Или, предположим, есть 5 типов объектов, каждый из которых ссылается на один и тот же справочник? Это тоже RelationAttribute или нечто другое или надо руками управляющий класс писать?
честно говоря не понял в чем проблема....
но кажется догадываюсь откуда ноги растут... важно понимать что если вы делаете какие-то изменения в объектной модели BLT их не "коммитит" в базу — зто тоже делаете вы.
наслаждайтесь
Dog>ComplexMapping. Но с этим как-то всё хитро...
да ну я тоже так думал, пока не разобрался
AB>>Может у кого был такой опыт, поделитесь.
Dog>BLT это маппер. Использовать его для общения с базой в простых случаях можно, но шаг в сторону и приходится что-то дописывать. Хотя, надо признаться, это совсем не сложно.
о_О BLToolkit.Mapping — тут про маппинг
BLToolkit.Data & BLToolkit.DataAccess — это про общение с базой =)
про допиливать — так оно так и позицианируется, как фреймворк для фреймворков
Dog>зы. Если у вас двухзвенка, возможно проще будет взять EF или Hibernate.
а эти навязывают вам свои "стратегии", в случае с BLT — вы навязываете ему свою стратегию, а не наоборот... а вот када Linq выйдет, тада вообще рай на земле наступит
ili>а эти навязывают вам свои "стратегии", в случае с BLT — вы навязываете ему свою стратегию, а не наоборот... а вот када Linq выйдет, тада вообще рай на земле наступит
а озвучивались какие-то сроки? я бы с удовольствием сполз бы с ling to sql на BLT (чего только стоит то чтоб сделать update надо сделать сначала select )
ili>наслаждайтесь
Уже давно Меня в общем больше интересовали практические примеры именно для справочников.
Dog>>зы. Если у вас двухзвенка, возможно проще будет взять EF или Hibernate. ili>а эти навязывают вам свои "стратегии", в случае с BLT — вы навязываете ему свою стратегию, а не наоборот... а вот када Linq выйдет, тада вообще рай на земле наступит
IT всё ещё колдует ?
Здравствуйте, cadet354, Вы писали:
ili>>а эти навязывают вам свои "стратегии", в случае с BLT — вы навязываете ему свою стратегию, а не наоборот... а вот када Linq выйдет, тада вообще рай на земле наступит C>а озвучивались какие-то сроки? я бы с удовольствием сполз бы с ling to sql на BLT (чего только стоит то чтоб сделать update надо сделать сначала select )
нет
как я понимаю IT делает его в "свободное" время на чистом антузиазме... хотя коммиты достаточно регулярные...
думаю, как закончит, призовёт бета-тестеров хотя... может сначала на своем банке испробует, но тада о багах в BLT мы узнаем из финансовых новостей
Здравствуйте, Dog, Вы писали:
Dog>Уже давно Меня в общем больше интересовали практические примеры именно для справочников.
нипанимаю я... чего там в этих справочниках такого проблемного? по сути любая таблица это справлочник...
в псевдокоде:
класс Подразделение
ID
класс Сотрудник
ID
ссылка Подразделение
класс ПодразделениеАксессор
ВыбратьПоКлючу(ключ)
ВыбратьВсе()
Удалить(Подразделение)
Вставить(Подразделение)
Обновить(Подразделение)
класс СотрудникАксессор
ВыбратьПоКлючу(ключ)
{
Сотрудник = SELECT
Сотрудник.Подразделение = ПодразделениеАксессор.ВыбратьПоКлючу(Сотрудник.Подразделение.ID)
return Сотрудник
}
ВыбратьВсе()
{
Список[Сотрудник] = SELECT
Список[Подразделение] = ПодразделениеАксессор.ВыбратьВсе()
ОтмапитьСписки(Список[Сотрудник], Список[Подразделение])
return Список[Сотрудник]
}
Удалить(Сотрудник)
Вставить(Сотрудник)
Обновить(Сотрудник)
Dog>>Уже давно Меня в общем больше интересовали практические примеры именно для справочников. ili>нипанимаю я... чего там в этих справочниках такого проблемного? по сути любая таблица это справлочник...
Практические примеры это не в плане как замапить на таблицу, это я асилил уже
Больше интересны архитектурные решения. Вот у меня допустим трехзвенка, несколько сервисов. Все они используют справочники. Справочники у сервисов повторяются. Хотелось бы минимизировать контракты сервисов, на клиенте кешировать справочники, отслеживать изменения и т.д. Что-то уже написано. Хотелось бы сравнить со "стандартными решениями"
ili>ну как пример... всё просто.
Ну когда их пару штук то да
Здравствуйте, ili, Вы писали:
AB>>Кто ответственен за удаление дочернего элемента при удалении его из списка? А кто должен его записывать при добавлении его в список? Будет он записан при записи объекта-родителя или нет? ili>а вот за все это отвечаете вы.
плохо
AB>>Или, предположим, есть 5 типов объектов, каждый из которых ссылается на один и тот же справочник? Это тоже RelationAttribute или нечто другое или надо руками управляющий класс писать? ili>честно говоря не понял в чем проблема.... ili>но кажется догадываюсь откуда ноги растут... важно понимать что если вы делаете какие-то изменения в объектной модели BLT их не "коммитит" в базу — зто тоже делаете вы.
не угадал. Смотри...
Есть таблица справочник, представленная тремя (для простоты) полями (oid, title, shorttitle).
Есть куча типов объектов, которые ссылаются на данный справочник, причем хранить просто Oid элемента справочника в объектах мне мало (в объектном представлении, на физическом уровне понятно что там просто oid). Т.е. мне нужно именно что поле типа ЭлементСправочника, чтобы были доступны поля .Title и .т.д.
1) Как это осуществить, чтобы библиотека сама создавала и читала такие объекты? ComplexMapping?
2) Если у меня в памяти окажется несколько тысяч разных объектов со ссылками на справочник, сколько будет объектов самого справочника? Несколько тысяч или один на каждую запись справочника?
Здравствуйте, AngeL B., Вы писали:
ili>>а вот за все это отвечаете вы.
AB>плохо
спорно, ИМХО — хорошо.
AB>не угадал. Смотри... AB>Есть таблица справочник, представленная тремя (для простоты) полями (oid, title, shorttitle). AB>Есть куча типов объектов, которые ссылаются на данный справочник, причем хранить просто Oid элемента справочника в объектах мне мало (в объектном представлении, на физическом уровне понятно что там просто oid). Т.е. мне нужно именно что поле типа ЭлементСправочника, чтобы были доступны поля .Title и .т.д. AB>1) Как это осуществить, чтобы библиотека сама создавала и читала такие объекты? ComplexMapping?
да, как пример приводил в соседнем посте
AB>2) Если у меня в памяти окажется несколько тысяч разных объектов со ссылками на справочник, сколько будет объектов самого справочника? Несколько тысяч или один на каждую запись справочника?
несколько тысяч. врожденного паттерна репозитарий в BLT нет.
я как-то пробовал с наскока его сделать на ObjectFactory да он (репозитарий) глючный оказался да и как в последствии выяснилось не шибко нужный (нам, разумеется не шибко нужный).
Здравствуйте, AngeL B., Вы писали:
AB>Здравствуйте, ili, Вы писали:
ili>>еще посмотрите Demo\WinForms (в исходниках)
AB>давно видел. AB>на что там смотреть??? на один объект Person хранимый в одной таблице и одну форму?
ровно на то как там в базу попадает этот самый Person и как он из нее берется
Здравствуйте, Dog, Вы писали:
Dog>Больше интересны архитектурные решения. Вот у меня допустим трехзвенка, несколько сервисов. Все они используют справочники. Справочники у сервисов повторяются. Хотелось бы минимизировать контракты сервисов, на клиенте кешировать справочники, отслеживать изменения и т.д. Что-то уже написано. Хотелось бы сравнить со "стандартными решениями"
нууу... я так честно признаюсь, что с 3-звенкой сталкивался только в "академическом" плане так что может сейчас чушь спорю.
про кэшировать справочники: а кто мешает? CacheAspect — вот вам кэш хоть на клиенте (своими руками тоже можно допилить под свои нужды ), хоть на сервере.. хотя, я, честно говоря, не понимаю зачем чего-то кэшировать на клиенте... он в 3-звенке вроде как "облегчается"... пущай всё чо надо у сервисов спрашивает, а то там могут поплыть всякие неприятности от того, что версии справочников в службе и на клиенте
будут отличаться.
ili>>ну как пример... всё просто. Dog>Ну когда их пару штук то да
кого? справочников? я честно говоря, не улавливаю особой разницы м\д 2 и 100 справочниками... поясни, плз
Здравствуйте, Dog, Вы писали:
Dog>А можно подробнее о стандартных решениях или ссылки...
Мы скорее всего говорим о разных вещах, но на всякий случай я поясню проблему.
Дело в том, что справочники (даже в классическом понимании) — это одна из ключевых вещей и проблем баз данных.
Самый простой способ — создать под каждый справочник отдельную таблицу. Это вариант номер один. Но у него неимоверное количество недостатков и только одно (для меня) достоинство — простота. Основные недостатки заключаются в том, что в таблицах повторяются поля, индексы, ограничения, а также то, что каждый справочник сам по себе.
Крайний случае такого подхода я видел на одной фирме, где в БД было около 450(!) таблиц, 70% которых были справочниками. Мне бы такого не хотелось. К тому же такие справочники могут хранить только абсолютно однотипные элементы.
Второй способ, — это создать древовидный справочник вида Dictionary(Oid, ParentOid, SequenceNo, Identity, Title, ShortTitle") и построить на его основе большинство справочников системы. Это часто используемый подход. Но он натыкается на одну неприятность. Есть справочники для которых нужны дополнительные данные. Например, справочник Единицы_Измерения. Там кроме названия необходимо иметь поле Scale которое показывает отношение единицы представленной в справочнике к стандартной (например, тонна — Scale = 1000). Куда расширять? Тут тоже несколько подходов: расширить саму таблицу Dictionary и добавить поле Scale туда. Но как ты понимаешь тогда придется туда же пихать дополнительные поля и в других подобных случаях. В больших системах получается некрасиво (до 20-25 справочников, требующих доп. полей).
создать дополнительную таблицу вида (Oid, Scale). Тогда нужны вьюхи и кучи триггеров для добавления/удаления/изменения последних или же чтобы бизнес объекты на уровне клиента сами могли писаться в разные таблице. Но тут тоже проблемы...
Плюс ко всему, как уже замечено, проблема целостности и оптимальности при работе со справочниками многих объектов сразу.
Короче... вот я и спрашиваю, может кто сталкивался с подобным при использовании BLT?
Dog>BLT это маппер. Использовать его для общения с базой в простых случаях можно, но шаг в сторону и приходится что-то дописывать. Хотя, надо признаться, это совсем не сложно. Dog>зы. Если у вас двухзвенка, возможно проще будет взять EF или Hibernate.
нет уж. EF сегодня это головняк, а Hib. меня бесит своими связями вынесенными в XML, что только усложняет задачу в больших задачах. К тому же тяжелые ORM-ы страдают врожденными пороками, которые в малых и средних задачах незаметны или заметны мало, а в больших или чересчур хитрых по данным приложениях начинают активно мешать. Об этом много уже писали, поищите.
Да и если бы я хотел, то у меня на руках DevExpress Ent. лежит, там XPO есть. Вполне себе ничего ORM. Но с одним крупным пороком. Насколько я понимаю там нельзя сделать выборку объектов из вьюхи или хранимой процедуры.
Здравствуйте, AngeL B., Вы писали:
AB>Короче... вот я и спрашиваю, может кто сталкивался с подобным при использовании BLT?
нуу вообще-то никто не заставляет придерживаться одного подхода во всем проекте — комбинируйте, делайте как вам удобно.
например, в текущем проекте, в начале я использовал разные таблицы, потом меня это достало, теперь у меня пользуется наследование в одной таблице для некоторых сущностей, некоторые сидят по разным, некоторые сидят в 2 таблицах сразу (правда в этом случае я поленился немножко, так что вторая таблица — в которой храняться расширенные свойства по сути есть комбинация необходимых столбцов из основной + дополнительные — но это, сугубо моя лень, и мне так показалось удобней )
AB>Короче... вот я и спрашиваю, может кто сталкивался с подобным при использовании BLT?
Я видимо изобрёл свой велосипед и скомбинировал 1 и 2 варианты
Dog>>зы. Если у вас двухзвенка, возможно проще будет взять EF или Hibernate. AB>Да и если бы я хотел, то у меня на руках DevExpress Ent. лежит, там XPO есть. Вполне себе ничего ORM. Но с одним крупным пороком. Насколько я понимаю там нельзя сделать выборку объектов из вьюхи или хранимой процедуры.
Читал отзывы про XPO. Пишут, что при увеличении сложности системы всё там накрывается медным тазом в плане производительности.
)
