.NET

индекс
121,07

Объектно-реляционный проектор собственного изготовления

В последних статьях заметил проявленный интерес к прослойкам между приложениями и базами данных. Решил поделиться описанием собственной разработки, которая длится уже два с половиной года, параллельно основной работе.


В 2007 году я устроился на работу программистом в небольшую фирму. В должность инженера-программиста на сопровождении одной госпрограммы. Программа была написана на Delphi с использованием базы MSSQL 2005. Ни делфи ни SQL я не знал, предпочитая C++ всем прочим языкам, пришлось осваивать на месте.
Первые месяцы работы были посвящены изучению базовых знаний, прохождениям тестов на sql-ex.ru, и работой. Основной задачей был разбор SQL скриптов доставшихся в наследство от прежних поколений разработчиков, и написание новых. Работать с базами приходилось постоянно и постепенно на смену интересу в изучении нового пришло понимание что надо что-то с этим делать.
В первую очередь была написана небольшая программка на делфи отображающая данные по базе(таблицы, столбцы, хранимки), позволявшая выполнять простые запросы в ней, и отображавшая результат. Затем добавлся поиск по всей базе данных. А затем меня перевели на другие проекты и показали C#.
Так как программка на делфи начала пользоваться популярностью у других разработчиков, принял решение переписать ее заново используя студию.
Весь код по работе с базой на тот момент занимал строк двести и отвечал только за поддержку подключения к базе и выполнение запросов.
Надо сказать что на тот момент я имел смутное представление про ООП и его принципы, вся работа с базой была вынесена в один класс. Все его возможности по генерации скриптов заключались в SELECT * FROM выбранная_таблица, и приписывании WHERE с несколькими простыми условиями. Т.е. она реализовала все необходимое по работе на тот момент.
В январе 2008 года мне дали первый проект на собственную разработку, проект заключался в создании dll'ки на шарпе, которая позволяла бы простым пользователям генерировать SQL запросы неограниченной сложности, и выполняла бы их отображая результат. Проект был написан за 4 месяца, и позволил переосмыслить множество вещей относительно авотматизации программерского труда. Собственно он и послужил толчком к продолжению работы над собственной прослойкой.
И да, к тому моменту я знал про NHibernate и ему подобные проекты, и даже немного использовал. Но наличие свободного времени, и желание иметь полный контроль над собственными разработками заставляли делать свое.
Все наработки были отвергнуты как несостоявшиеся. Было произведено разделение задач между классами, доработка способов подключения. Контроль над исключениями и много другое.

На сегодня прослойка имеет представление в виде dll'ки, и умеет делать множество полезных вещей, постоянно работая с базами данным, я уже давно не писал SQL запросы вручную. Вот основной и краткий перечень возможностей:
  • Автогенерация кода, наиболее важное достижение на мой взгляд. Я просто указываю нужную мне базу и сразу получаю готовый код на C# полностью отражающий структуру таблиц, и позволяющий мне работать с базой как с набором класов и объектов
  • Генерация SQL запросов. Прослойка позволяет создавать SQL запросы почти любой сложности. Также есть возможность создания именованных фильтров с их последующим применением. На сегодня не хватает возможности построения условий типа «Таблица.поле Операция Таблица.поле», и join подключений. В планах доработка.
  • Асинхронные запросы. Можно создать объект класса асинхронного запроса, передать ему запрос, функцию которую необходимо выполнить перед запросом, и функцию которая выполнится после запроса, и в которую будет передан его результат. Затем закинуть его в очередь и он будет выполнен в фоновом потоке не блокируя основной процесс.
  • Начав применять прослойку в web-разработке столкнулся с проблемой одновременного доступа к рессурсам. Переработав получил вполне приемлимую поддержку одновременного доступа к приложению. Тест прогоняющий 100 потоков параллельно в каждом из которых вызывается 100 INSERT'ов через прослойку выполняется корректно и без потерь.
  • Кэширование данных. Реализовано три вида кэша: простой, обновляемый по запросу, автообновляемый по таймеру.
  • Создание бэкапа базы, и восстановление из него.
  • Ведение журнала ошибок.


В последней версии добавлена возможность одновременного подключения к нескольким базам. Впрочем проектов использующих несколько баз одновременно у меня пока нет, поэтому оптимальным решением мне кажется разделение проектора на три части: полнофункциональный(несколько баз), полнофункциональный(одна база) и простой, в котором все редкоиспользуемые навороты будут отключены.

Минусы которые вижу я:
  • Недоработка генерации сложных условий, главным препятствием сейчас является отсутствие идеи, как сделать наиболее удобным их задание программистом при использовании прослойки.
  • При использовании прослойки в web servic'е возникла проблема сохранения файла журнала на диск. Сейчас ведется исправление и переработка ведения журнала в принципе.
  • Отсутствие документации. На хватает времени.


Если заинтересует:
ifolder.ru/17678800
В архиве dll'ка, небольшой демо-проект, и совсем немного документации по началу работы. Если интересен код, рефлектор все покажет.
Критика в принципе приветствуется, если конструктивная. И хочу заметить, проект делается только под свои нужды.

Исходники (версия последняя, непротестированная, нет времения на доработку в текущий период):
ifolder.ru/17679675


P.S. По сути данный ОРП, просто сборник накопленных знаний за период работы с базами, оформленный в рабочий инструмент, причем часть из этих знаний включена просто чтобы не забыть, и не несет особо полезной функциональной нагрузки.
+5
12 мая 2010, 19:04
4

комментарии (27)

0
alexs0ff #
А что без исходников самой ORM?
0
Ogoun #
Выложил.
0
alexs0ff #
Была мысль сделать его СУБД независимым?
0
Ogoun #
Есть в ближайших планах научить его работать с SQLLite.
0
ashmind #
готовый код на C# полностью отражающий структуру таблиц, и позволяющий мне работать с базой как с набором класов и объектов

То есть это не полный mapper, а вариант Active Record? Чем он лучше, чем LINQ-to-SQL?
–1
Ogoun #
Поясню.
1. LINQ-to-SQL, это уже Framework 3.5, мне же необходима поддержка приложений со второго.
2. Мне необходима собственная генерация файлов с кодом по отображению таблиц, которую я в любой момент могу подправить и получить желаемое.
3. Мне приятно писать свою разработку.
4. В любой момент могу интегрировать в прослойку необходимый мне функционал, или убрать лишнее.
0
Ogoun #
И да, напоминает Active Record. Правда только в части отражения структуры таблиц. Например в прослойке кроме отражения полей таблицы, создаются дополнительно поля позволяющие обращаться к связанным таблицам.
0
LexL #
Framework 3.5 это тот же Framework 2.0 SP2 с несколькими дллками.

В чем проблема положить в папку приложения System.Core.dll и System.Data.Linq.dll и поддерживать второй фреймворк?
0
Ogoun #
Проблемы нет, но зачем? Острой необходимости в использовании LINQ нет.
0
LexL #
Читаю твое пояснение №1 -> LINQ-to-SQL

Т.е. надо или не надо? Или ты еще не определился?

Если не определился, объясняю, что LIQN-to-SQL поддерживается и во втором фреймворке, нужно только 2 библиотеки в проект добавить
0
lair #
Есть.

«Недоработка генерации сложных условий, главным препятствием сейчас является отсутствие идеи, как сделать наиболее удобным их задание программистом при использовании прослойки. „

LINQ как раз для этого предназначен.
0
mezastel #
Немного офтоп: было бы круто если бы кто-то написал про bltoolkit.
0
Ogoun #
На RSDN'е вполне неплохо уже описали:
projects.rsdn.ru/RFD/wiki/WikiStart
0
graninas #
Ни делфи ни SQL я не знал, предпочитая C++ всем прочим языкам, пришлось осваивать на месте.

0
graninas #
Пардон, нажал не ту кнопку…
0
LexL #
Ну зато просек, откуда у C# корни растут :)
0
graninas #
Что-то я не вижу особой связи… C#, пожалуй, имеет большее отношение к идеям java (судя по рассказам C#-программистов), чем к С++. А ООП — понятие не конкретного языка, а парадигма программирования, и она может быть использована даже в языках, где нет поддержки классов.
0
LexL #
Я вообще-то Дельфю имел ввиду ;) тот же автор
0
graninas #
Поясните, пожалуйста, что за «тот же автор».
0
DunkanVS #
Разработчик библиотеки VCL и .NET один и тот же человек. Если внимательно на них посмотреть можно найти много общего.

«Андерс Хейльсберг известен как создатель компилятора Borland Turbo Pascal и ведущий конструктор технологии Borland Delphi. За время его работы в Microsoft с 1996 года главной его заслугой считается создание языка Cool, позже переименованного в C#, и задумывавшегося как убийца Java»
0
graninas #
А что, интересный факт, спасибо, я не знал.

Хочу добавить личные впечатления о библиотеках. VCL был хорош, на острие передовых технологий, со значительным функционалом. Плох он тоже был в чем-то. Про .NET я знаю слишком мало, чтобы оценивать. Что мне по-настоящему нравится, — это система Qt'а. Я пишу на нем.
0
graninas #
Я что хотел сказать.

Вы, конечно, большой молодец, делаете нужные и правильные вещи. Что вы всему научились, — это тоже очень здорово. Возможно даже, ваша ORM хороша в каких-то отношениях.

Меня насторожили вот эти слова:
"… ни SQL я не знал, предпочитая C++ всем прочим языкам, пришлось осваивать на месте."
«Надо сказать что на тот момент я имел смутное представление про ООП и его принципы».
Вы писали на С++, не используя ООП, и вас взяли на должность инженера-программиста без этих знаний, — это весьма, весьма странно.
0
Ogoun #
Именно так и взяли. Собственно все с чего-то начинают. И странного тут я не вижу. Без работы получить нормальный опыт, на мой взгляд, нереально.
0
graninas #
Без обид, но видел я работу «программиста», который учился программированию на ходу, да и то не стал программистом. Ваша ситуация похожа, за исключением, что вы пришли к идее ORM-системы, развились, обучились, получили опыт, — честь вам и хвала. А вот тот «программист», мой предшественник, так ничего и не понял, но гонору… Как результат — теперь каждый день мне и напарнику приходится поддерживать тупейшую программу, без которой на предприятии никак. И мы пишем новую, однако, из-за тупости первой возникает такое количество ошибок, что на программирование не хватает времени и сил.

А нормальный опыт получить очень даже реально. Его можно получить в ВУЗе, занимаясь самообучением; его можно получить в фрилансе, а так же на обычной работе, будучи стажером. Но вот так сразу на должность инженера-программиста, — это, мягко говоря, значительный аванс.

Хотя если быть честным, то, возможно, во мне говорит что-то вроде зависти или негодования, так что прошу не обижаться и меня извинить. При прочих равных (а я, кстати, тоже свою ORM пишу и много чего еще делаю), моя должность — техник-программист. Наверно, от этого я такой злой. Так что не воспринимайте остро мои слова, продолжайте идти своей дорогой.

С уважением.
0
ostapbender #
Ну что сказать… Каждый программист в определенный момент своего развития просто обязан написать подобие ORM. В большинстве случаев аргументы ровно такие же, как у вас — «полный контроль», «я сделаю лучше» да и просто NIH. Это все понятно, проходили, знаем.

Итог в большинстве случаев предсказуем. Получается библиотека, которую дальше развивать проблематично в силу имманентных архитектурных косяков, но и избавиться от нее тоже непросто — большая часть кода проекта оказывается очень сильно привязана к ее потрохам и деталям реализации.

Мой вам совет: бросайте это дело. То, что есть сейчас — без обид — мало куда годится. Вполне себе хороший кэш есть и в ASP.NET, а написать к нему прослойку в виде ICache — дело двух рабочих дней. Кодогенератор тоже откровенно слабый — посмотрите хотя бы на T4 или Spark View Engine. Формирование SQL-запросов гвоздями приколочено к SQL Server и тоже не блещет. Самое главное — именно маппинг — вообще никуда не годится. Почитайте Фаулера по поводу Identity Map, Unit of Work и т.д. У него вообще довольно много по маппингу.

Если же чувствуете, что можете изменить сложившийся мир ORM-ов, то развивать текущий проект тем более нет смысла — ему некуда больше расти.
0
Ogoun #
Вообще согласен. Просто на текущий момент времени для всех проектов которые пишу, этого вполне хватает. И как уже говорилось, для собственного опыта писалось. За материалы спасибо, посмотрю.
0
lair #
«Прослойка позволяет создавать SQL запросы почти любой сложности.»
Вот в это «почти» (особенно если у вас нет языка запросов) все всегда и упирается.

«Асинхронные запросы. Можно создать объект класса асинхронного запроса, передать ему запрос, функцию которую необходимо выполнить перед запросом, и функцию которая выполнится после запроса, и в которую будет передан его результат. Затем закинуть его в очередь и он будет выполнен в фоновом потоке не блокируя основной процесс.»
Задача на использование ThreadPool на десять минут.

«Ведение журнала ошибок. / При использовании прослойки в web servic'е возникла проблема сохранения файла журнала на диск. Сейчас ведется исправление и переработка ведения журнала в принципе. „
log4net вам чем не угодил?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.