Обычно для небольшого числа таблиц обходился тем что Data layer представлял собой классы для доступа к таблицам с набором методов типа Add, Update, Delete GetList<X> и прочее
Но сейчас вот столкулся с тем что в задаче используется 150 таблиц. Даже если их довольно сильно сгруппировать
то всеравно получаем где 40 классов для Data layer. Чето слишком хадкордно получается.
Как можно обойтись без создания отдельных классов для таблицы/группы таблиц в Data layer, и при этом сохранив гибкость? Что применить? Один класс доступа — так получится нагрузка чрезмерная на него. Специальные компоненты баз данных для доступа типа 0040 — хз, не пробывал, как оно будет работать.
Здравствуйте, lazymf, Вы писали:
L>Здравствуйте, LaFlour, Вы писали:
LF>>Один класс доступа — так получится нагрузка чрезмерная на него.
L>А что значит в данном контексте "чрезмерная нагрузка"?
Штук 5 классов — бизнес логика работает с нужными DB классами.
1 класс — все ломятся через один — имхо начинаем синхронизировать все подряд, ибо для 2х десятков клиентов картина почемуто пока вырисовываться не очень радужная.
Или я ошибаюсь? Просто не приходилось через один DB класс все реализовывать. постоянно было их несколько.
Здравствуйте, LaFlour, Вы писали:
LF>Штук 5 классов — бизнес логика работает с нужными DB классами. LF>1 класс — все ломятся через один — имхо начинаем синхронизировать все подряд, ибо для 2х десятков клиентов картина почемуто пока вырисовываться не очень радужная.
Стоп. Мы что считаем-то — классы или экземпляры? Я думал что классы. Если экземпляры — то зачем бизнес-логике для доступа ко всем данным использовать один экземпляр универсального шлюза? Пускай будет по одному на каждую таблицу (или представление). Но все эти экземпляры будут экземплярами одного класса — универсального шлюза.
LF>Или я ошибаюсь? Просто не приходилось через один DB класс все реализовывать. постоянно было их несколько.
Ну, в системах на ADO люди как-то работают с любыми БД через один класс — ADO Recordset, и ничего.
Если в БД 150 таблиц, значит нужно 150 классов для представления типов записей этих таблиц как объектов и еще 150 классов для представления самих таблиц как агрегатов объектов первых 150 классов. Итого нужно 300 классов. Написать их вручную будет чрезмерно утомительно. Поэтому напишите программу-кодогенератор, которая законнектится к Ораклу, вытащит из него метаинформацию о таблицах (типы полей, первичные ключи, фореджин ключи и т.д.) и на основе этой метаинформации сама сгенерирует необходимый исходный код для 300 классов. Написать кодогенератор не сложно (за неделю можно справиться, по крайней мере у меня на это дело ушла неделя) зато потом его можно будет использовать для любой оракловой базы данных, а количество таблиц в ней уже не будет иметь ни какого значения.
LF>Ситуация: 3х звенное приложение, Oracle сервер, 150 таблиц.
LF>Обычно для небольшого числа таблиц обходился тем что Data layer представлял собой классы для доступа к таблицам с набором методов типа Add, Update, Delete GetList<X> и прочее
LF>Но сейчас вот столкулся с тем что в задаче используется 150 таблиц. Даже если их довольно сильно сгруппировать LF>то всеравно получаем где 40 классов для Data layer. Чето слишком хадкордно получается.
LF>Как можно обойтись без создания отдельных классов для таблицы/группы таблиц в Data layer, и при этом сохранив гибкость? Что применить? Один класс доступа — так получится нагрузка чрезмерная на него. Специальные компоненты баз данных для доступа типа 0040 — хз, не пробывал, как оно будет работать.
Преимущества доступа через один класс заканчиваются с завершением дизайна — т.е. уже закодить реализацию будет не проще, чем задизайнить адекватную предметной области иерархию преобразователей данных. Мне кажется, трудозатраты не удастся сэкономить таким способом. К тому-же реализацию CRUD методов можно вынести в супертип слоя — и работа сведется к немного скучному, но не сложному описанию соответствий м/у полями таблиц и членами классов. Лучше сделать по мапперу на бизнес-объект (1 общую функциональность можно вынести в супертип; 2 некоторые объекты не могут существовать вне контекста некоего аггрегирующего объекта — это позволяет сократить количество классов доступа к БД).
Все это, естественно, ИМХО.
Здравствуйте, lazymf, Вы писали:
L>Здравствуйте, LaFlour, Вы писали:
LF>>Штук 5 классов — бизнес логика работает с нужными DB классами. LF>>1 класс — все ломятся через один — имхо начинаем синхронизировать все подряд, ибо для 2х десятков клиентов картина почемуто пока вырисовываться не очень радужная.
L>Стоп. Мы что считаем-то — классы или экземпляры? Я думал что классы. Если экземпляры — то зачем бизнес-логике для доступа ко всем данным использовать один экземпляр универсального шлюза? Пускай будет по одному на каждую таблицу (или представление). Но все эти экземпляры будут экземплярами одного класса — универсального шлюза.
Я про классы.
Теперь представляем себе такую картину. Таблицы [заказчики], [платежки]
<<db layer>>: 2 класса "dbCustomer", "dbInvoice" у каждого есть
а) методы с одинакомым названием Add, Update, Delete — но разной сигнатурой.
б) специфичные методы типа GetCustomersList, GetMonthInvoiceList
вынососить все в один класс както не особо получается. Организовывать иерархию для 5ти еще както можно (но проще создать отдельные классы для каждой таблицы), но для 150 таблиц гмммм.
Что посоветуете?
LF>>Или я ошибаюсь? Просто не приходилось через один DB класс все реализовывать. постоянно было их несколько. L>Ну, в системах на ADO люди как-то работают с любыми БД через один класс — ADO Recordset, и ничего.
и тут ADO, но для каждого класса <<db layer>> свой коннект
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, LaFlour, Вы писали:
LF>>Ситуация: 3х звенное приложение, Oracle сервер, 150 таблиц.
SYG>Если в БД 150 таблиц, значит нужно 150 классов для представления типов записей этих таблиц как объектов и еще 150 классов для представления самих таблиц как агрегатов объектов первых 150 классов. Итого нужно 300 классов. Написать их вручную будет чрезмерно утомительно. Поэтому напишите программу-кодогенератор, которая законнектится к Ораклу, вытащит из него метаинформацию о таблицах (типы полей, первичные ключи, фореджин ключи и т.д.) и на основе этой метаинформации сама сгенерирует необходимый исходный код для 300 классов.
А как же быть со спецификой методов для этих 300 классов? Ведь у каждого класса есть общие методы и есть специфичные, в зависимости от функциональности
Здравствуйте, g_i, Вы писали:
LF>>Ситуация: 3х звенное приложение, Oracle сервер, 150 таблиц.
LF>>Но сейчас вот столкулся с тем что в задаче используется 150 таблиц. Даже если их довольно сильно сгруппировать LF>>то всеравно получаем где 40 классов для Data layer. Чето слишком хадкордно получается.
LF>>Как можно обойтись без создания отдельных классов для таблицы/группы таблиц в Data layer,
g_i>Преимущества доступа через один класс заканчиваются с завершением дизайна — т.е. уже закодить реализацию будет не проще, чем задизайнить адекватную предметной области иерархию преобразователей данных. Мне кажется, трудозатраты не удастся сэкономить таким способом. К тому-же реализацию CRUD методов можно вынести в супертип слоя — и работа сведется к немного скучному, но не сложному описанию соответствий м/у полями таблиц и членами классов. Лучше сделать по мапперу на бизнес-объект (1 общую функциональность можно вынести в супертип; 2 некоторые объекты не могут существовать вне контекста некоего аггрегирующего объекта — это позволяет сократить количество классов доступа к БД). g_i>Все это, естественно, ИМХО.
Вы имеете в виду что постараться по максимуму привязаться по правилу 1 бизнес объект — 1-5 дата объектов? распределив 150 таблиц по этим сгруппированным дата классам?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, LaFlour, Вы писали:
LF>>Ситуация: 3х звенное приложение, Oracle сервер, 150 таблиц.
SYG>Если в БД 150 таблиц, значит нужно 150 классов для представления типов записей этих таблиц как объектов и еще 150 классов для представления самих таблиц как агрегатов объектов первых 150 классов. Итого нужно 300 классов. Написать их вручную будет чрезмерно утомительно. Поэтому напишите программу-кодогенератор, которая законнектится к Ораклу, вытащит из него метаинформацию о таблицах (типы полей, первичные ключи, фореджин ключи и т.д.) и на основе этой метаинформации сама сгенерирует необходимый исходный код для 300 классов. Написать кодогенератор не сложно (за неделю можно справиться, по крайней мере у меня на это дело ушла неделя) зато потом его можно будет использовать для любой оракловой базы данных, а количество таблиц в ней уже не будет иметь ни какого значения.
Это работает если одному классу предметной области соответсвует одна таблица БД. Если нет — придется изготовить промежуточный слой, который будет упаковывать отдельные объекты, возвращенные DAL, в объекты логики бизнес-приложения. Это первое.
Второе — при раздельном доступе к таблицам БД снижается производительность системы. Пример: имеем table1, table2. table2.idTable1(FK)->table1.id. Какие дейтсвия должна произвести система для загрузки данных из таблицы table1? Выполнить для каждого объекта, построенного из table1 запрос к table2? Или построить запрос, извлекающий данные из обеих таблиц одновременно (увеличит на порядки скорость выборки, но позволяет ли предлагаемая система лугко корректировать поведение загнрузчиков данных)?
Здравствуйте, LaFlour, Вы писали:
LF> б) специфичные методы типа GetCustomersList, GetMonthInvoiceList LF>вынососить все в один класс както не особо получается. Организовывать иерархию для 5ти еще както можно (но проще создать отдельные классы для каждой таблицы), но для 150 таблиц гмммм.
Заменить специфичные методы на один GetRelatedRecords? А все остальное вынести в бизнес-логику?
А вообще, может расскажешь поподробнее про задачу, а то я пока себе слабо представляю о чем идет речь — как-то не стыкуется у меня упомянутая тобой несложная бизнес-логика на 5 классов и 150 таблиц...
Здравствуйте, LaFlour, Вы писали: LF>А как же быть со спецификой методов для этих 300 классов? Ведь у каждого класса есть общие методы и есть специфичные, в зависимости от функциональности
Ну, на самом деле большинство из этих "специфичных" методов — это что-то типа Order.GetItems и Item.GetOrder — т.е. банальные навигаторы по foreign key.
Как правило, в подобных случаях "ручной" код — это тонкая пленочка поверх конструкторов, навигаторов, и аксессоров с модифаерами. А все это генерится автоматически.
... << RSDN@Home 1.1.4 @@subversion >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, LaFlour, Вы писали:
LF>Вы имеете в виду что постараться по максимуму привязаться по правилу 1 бизнес объект — 1-5 дата объектов? распределив 150 таблиц по этим сгруппированным дата классам?
В общем, да. Но вообще, выбор архитектуры напрямую зависит от сложности предметной области. Т.е. для простых систем с простой структурой отношение "один класс — одна таблица" допустимо и описывается моделью "активная запись" или "шлюз данных". Для сложных (с отношениями м/у классами и таблицами "один ко многим" ) — "модель предметной облаасти" (с использованием преобразователей данных) или "модуль таблицы" (напрямую поддерживается .Net с ее датасетами).
На эту тему мне понравилась книга Мартина Фаулера "Архитектура корпоративных программных приложений" — мне кажется, то что тебе нужно (содержит типовые решения проблем разработки).
Здравствуйте, lazymf, Вы писали:
L>Здравствуйте, LaFlour, Вы писали:
LF>> б) специфичные методы типа GetCustomersList, GetMonthInvoiceList LF>>вынососить все в один класс както не особо получается. Организовывать иерархию для 5ти еще както можно (но проще создать отдельные классы для каждой таблицы), но для 150 таблиц гмммм.
L>Заменить специфичные методы на один GetRelatedRecords? А все остальное вынести в бизнес-логику?
ну, так не из бизнес слоя ж работать с данными напрямую — нужен <<db layer>>
L>А вообще, может расскажешь поподробнее про задачу, а то я пока себе слабо представляю о чем идет речь — как-то не стыкуется у меня упомянутая тобой несложная бизнес-логика на 5 классов и 150 таблиц...
Я имел в виду что более 5-10 классов для бизнес логики, DB слоя и десятка таблиц не приходилось работать. я просто создавал для каждого бизнес класса 1-2 класс для DB слоя, и каджый класс DB слоя работал с 1-2 related таблицами через свой ADO коннект.
Но теперь новая задача где всего в 15 раз больше. не сколько в бизнес слое — сколько в данных.
Вот и сейчас не знаю что делать. Прошлая практика таблица-DB класс пугает.
Хочется найти выход и узнать кто как реализовывал DB слой для 100 таблиц.
Здравствуйте, LaFlour, Вы писали:
LF>ну, так не из бизнес слоя ж работать с данными напрямую — нужен <<db layer>>
Зависит от сложности бизнес-слоя, я тут тебя неверно понял и решил что бизнес-логика какая-то совсем тривиальная — но поскольку это не так — забудь.
LF>Но теперь новая задача где всего в 15 раз больше. не сколько в бизнес слое — сколько в данных. LF>Вот и сейчас не знаю что делать. Прошлая практика таблица-DB класс пугает. LF>Хочется найти выход и узнать кто как реализовывал DB слой для 100 таблиц.
Ну тут остается, имхо, два варианта — 1) кодогенерация на основании структуры БД и 2) преобразователь данных. Порекомендовать что-то из этой парочки затрудняюсь, сильно зависит от твоей конкретной ситуации.
Здравствуйте, g_i, Вы писали:
g_i>Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>>Здравствуйте, LaFlour, Вы писали:
LF>>>Ситуация: 3х звенное приложение, Oracle сервер, 150 таблиц.
SYG>>Если в БД 150 таблиц, значит нужно 150 классов для представления типов записей этих таблиц как объектов и еще 150 классов для представления самих таблиц как агрегатов объектов первых 150 классов. Итого нужно 300 классов. Написать их вручную будет чрезмерно утомительно. Поэтому напишите программу-кодогенератор, которая законнектится к Ораклу, вытащит из него метаинформацию о таблицах (типы полей, первичные ключи, фореджин ключи и т.д.) и на основе этой метаинформации сама сгенерирует необходимый исходный код для 300 классов.
g_i>Это работает если одному классу предметной области соответсвует одна таблица БД. Если нет — придется изготовить промежуточный слой, который будет упаковывать отдельные объекты, возвращенные DAL, в объекты логики бизнес-приложения. Это первое.
группировка related таблиц?
g_i>Второе — при раздельном доступе к таблицам БД снижается производительность системы. Пример: имеем table1, table2. table2.idTable1(FK)->table1.id. Какие дейтсвия должна произвести система для загрузки данных из таблицы table1? Выполнить для каждого объекта, построенного из table1 запрос к table2? Или построить запрос, извлекающий данные из обеих таблиц одновременно
раньше просто из объекта для Table1 выполнял запрос и все.
Здравствуйте, LaFlour, Вы писали:
LF>а все остальное по многозвенкам что читал — не затрагивали вопрос этот в плане большого кол-ва таблиц.
Вот чем эта книжка мне и понравилась — там эта проблема (построение слоя доступа к БД) более-менее детально разобрана, в отличие от большинства других источников.
Здравствуйте, lazymf, Вы писали:
LF>>Но теперь новая задача где всего в 15 раз больше. не сколько в бизнес слое — сколько в данных. LF>>Вот и сейчас не знаю что делать. Прошлая практика таблица-DB класс пугает. LF>>Хочется найти выход и узнать кто как реализовывал DB слой для 100 таблиц.
L>Ну тут остается, имхо, два варианта — 1) кодогенерация на основании структуры БД и 2) преобразователь данных. Порекомендовать что-то из этой парочки затрудняюсь, сильно зависит от твоей конкретной ситуации.
