Comments 19
А что мешало использовать стандартные строки подключения или хотя бы нормальные кастомные секции конфигурации вместо этого ужаса с appSettings и нумерованными значениями? Зачем нужен год-класс, чем вам стандартная модель Connection/Command не угодила? Вы бы хоть описали, что вам не так в npgsql…
Ну и как-то странно вообще…
Ну и как-то странно вообще…
>> Что мешало использовать стандартные строки подключения…
— возможно знания или исходил из того, что может смениться БД, но на тот момент я не нашел ничего лучше кроме appSettings
>> нумерованными значениями
— нумерованные значения были использованы, для нумерации модулей. Никто не мешает вместо нумерации использовать наименование модулей, например:
>>Зачем нужен год-класс, чем вам стандартная модель Connection/Command не угодила?
класс нужен для работы с ObjectDataSource, и дальнейшем подсоединении его к гриду
>>Вы бы хоть описали, что вам не так в npgsql
1. Для того что бы создать и заполнить DataSet результатом SQL запроса нужно
— создать сам датасет
— создать адаптер
— заполнить датасет данными из адаптера
а тут это делается одной строчкой
аналогично с заполнением параметров «команды» и т.п.
одним словом идет сокращение кода
2. Работа со схемами. По умолчанию работал со схемой public, для других схем нужно пописывать наименование схемы в коде, например
и при переименовании схемы, нужно исправлять все sql запросы, а тут за счет
достаточно будет изменить только параметр в конфиге
— возможно знания или исходил из того, что может смениться БД, но на тот момент я не нашел ничего лучше кроме appSettings
>> нумерованными значениями
— нумерованные значения были использованы, для нумерации модулей. Никто не мешает вместо нумерации использовать наименование модулей, например:
<add key="UserNameCore" value="UserNameCore" />
<add key="PasswordCore" value="PasswordCore" />
<add key="SchemaCore" value="SchemaCore" />
<!-- Данные подключения к БД для 1го модуля системы -->
<add key="UserNameMod1" value="UserNameModule1" />
<add key="PasswordMod1" value="PasswordModule1" />
<add key="SchemaMod1" value="SchemaModule1" />
>>Зачем нужен год-класс, чем вам стандартная модель Connection/Command не угодила?
класс нужен для работы с ObjectDataSource, и дальнейшем подсоединении его к гриду
>>Вы бы хоть описали, что вам не так в npgsql
1. Для того что бы создать и заполнить DataSet результатом SQL запроса нужно
— создать сам датасет
— создать адаптер
— заполнить датасет данными из адаптера
а тут это делается одной строчкой
CreateDataSet(ds, 'Select * from ~vyear~')
аналогично с заполнением параметров «команды» и т.п.
одним словом идет сокращение кода
2. Работа со схемами. По умолчанию работал со схемой public, для других схем нужно пописывать наименование схемы в коде, например
Select * from myschema.mytable
и при переименовании схемы, нужно исправлять все sql запросы, а тут за счет
Select * from ~mytable~
достаточно будет изменить только параметр в конфиге
возможно знания или исходил из того, что может смениться БД, но на тот момент я не нашел ничего лучше кроме appSettings
Стандартный механизм хранения connectionStrings? .settings-файлы? Кастомные секции? «Тот момент» уже никого не интересует, на дворе 2014-ый год, все эти решения — мейнстрим.
класс нужен для работы с ObjectDataSource, и дальнейшем подсоединении его к гриду
Для работы с ObjectDataSource нужен провайдер данных с определенным контрактом, а не год-класс. Соответственно, все, что нужно было в вашем случае — если вы решали именно эту задачу — это создать базовый класс для таких провайдеров, работающий с постгре, и инкапсулировать все поведение в нем.
Для того что бы создать и заполнить DataSet результатом SQL запроса нужно
Зачем вам датасет?
CreateDataSet(ds, 'Select * from ~vyear~')Методы Create* должны возвращать результат, а не принимать его.
при переименовании схемы, нужно исправлять все sql запросы
Переименование схемы — это изменение структуры БД, оно должно вести к изменению sql-запросов.
А вообще, хорошо видно, что вам давно пора познакомиться с понятием ORM и тем, что в этой области сделали за последние годы.
Хорошо, спасибо.
Посмотрю как время будет.
Основная работа у меня на Delphi, поэтому с C# знаком только поскольку постольку.
Посмотрю как время будет.
Основная работа у меня на Delphi, поэтому с C# знаком только поскольку постольку.
Переименование схемы — это изменение структуры БД, оно должно вести к изменению sql-запросов.
Зачем из за изменения названия схемы, изменять все SQL запросы, когда можно это все автоматизировать и сэкономить время?
А как так вышло, что у вас название схемы изменилось, а название (и, что важнее) семантика объектов в ней — нет?
В проекте изначально было принято решение, разделять на схемы по модулям, затем было решение произвести объединение некоторых схем по процессам. В итоге вместо нескольких схем, стала одна.
думаю возник сразу пару вопросов:
— одинаковые таблицы
Одинаковые таблицы, если такие имелись, сливались в одну ( по данным ). Смысл и структура таблиц с одинаковыми названиями были одинаковыми. Ключ в таблице было поле, не ID а GUID ( проблем с объединением не было )
— одинаковые вьюшки (представления)
Опять таки они совпадали, и во многих случаях это были прообразы вьющек из других схем ( которые объединились)
думаю возник сразу пару вопросов:
— одинаковые таблицы
Одинаковые таблицы, если такие имелись, сливались в одну ( по данным ). Смысл и структура таблиц с одинаковыми названиями были одинаковыми. Ключ в таблице было поле, не ID а GUID ( проблем с объединением не было )
— одинаковые вьюшки (представления)
Опять таки они совпадали, и во многих случаях это были прообразы вьющек из других схем ( которые объединились)
То, что у вас происходит — это рефакторинг. В этом случае, у вас должен меняться код, делать такие вещи настройкой — неправильно.
Код меняется, только во вьюшках (представлениях).
Клиентская часть остается неизменной. Почему не правильно, если все работает и ничего этому не мешает?
Клиентская часть остается неизменной. Почему не правильно, если все работает и ничего этому не мешает?
Потому что у вас поменялась структура БД, а вы, вместо того, чтобы соответственно ей поменять приложение, делаете костыль.
Я не считаю это костылем, это дополнительная опция.
В такой ситуации (переименование схемы) Вы поступаете:
Вар. 1. берете, изучаете каждый запрос и переписываете. (в каждом запросе меняете наименование схемы)
Вар. 2. берете допустим String Replace и делаете массовую замену «схема1.» на «схема2.»
В обоих вариантах возможны ошибки, где то что то не доглядели, где то что то заменили не так. И тратите время…
В Delphi, есть компоненты для работы с БД, там сразу в конекшене прописывается имя схемы при необходимости. Тут все так же.
В такой ситуации (переименование схемы) Вы поступаете:
Вар. 1. берете, изучаете каждый запрос и переписываете. (в каждом запросе меняете наименование схемы)
Вар. 2. берете допустим String Replace и делаете массовую замену «схема1.» на «схема2.»
В обоих вариантах возможны ошибки, где то что то не доглядели, где то что то заменили не так. И тратите время…
В Delphi, есть компоненты для работы с БД, там сразу в конекшене прописывается имя схемы при необходимости. Тут все так же.
А для переименования таблиц у вас есть такая же опция? А для переименования колонок?
Еще раз: у вас изменилась структура БД, вы должны анализировать и менять код. Ваше решение нужно тогда, когда есть много разных компонентов, каждый из которых смотрит на БД одной и той же структуры, но с разным именем схемы.
Еще раз: у вас изменилась структура БД, вы должны анализировать и менять код. Ваше решение нужно тогда, когда есть много разных компонентов, каждый из которых смотрит на БД одной и той же структуры, но с разным именем схемы.
О ужс.
— Что значит s в sYear?
— Вы про ORM слышали?
— Этот пост пролежал в черновиках 10 лет?
— Что значит s в sYear?
— Вы про ORM слышали?
— Этот пост пролежал в черновиках 10 лет?
А чем вам using конструкция не угодила?
И зачем явно освобождать память?
GC не разберется?
И зачем явно освобождать память?
GC не разберется?
я тебя породил я тебя и убью
1. для оптимизации приложения, все соединения с БД лучше закрыть сразу.
2. класс использует объект, который реализует метод Dispose, следуя правилу №2 из одной статьи на хабре , нужно использовать dispose
— Правило первое: не применять (до тех пор, пока это действительно не понадобится)
— Правило второе: для класса, владеющего управляемыми ресурсами, реализуйте IDisposable (но не финализатор)
— Правило третье: для класса, владеющего неуправляемыми ресурсами, реализуйте IDisposable и финализатор
1. Не спорю.
2. Опять же не спорю.
Но на мои вопросы вы не ответили, поясню :)
В c# есть такой оператор using с ним бы ваш код был бы понятнее.
По поводу освобождения, мне кажется, что тут у вас не какие то космические расчеты, которые нельзя доверить GC для освобождения памяти.
Ну и к переводу указанной вами статьи у меня есть небольшая претензия:
Dispose метод — это и есть финализатор. То, что в этой статье называется финализатором, принято называть деструктором.
2. Опять же не спорю.
Но на мои вопросы вы не ответили, поясню :)
В c# есть такой оператор using с ним бы ваш код был бы понятнее.
По поводу освобождения, мне кажется, что тут у вас не какие то космические расчеты, которые нельзя доверить GC для освобождения памяти.
Ну и к переводу указанной вами статьи у меня есть небольшая претензия:
Dispose метод — это и есть финализатор. То, что в этой статье называется финализатором, принято называть деструктором.
Да, в приведенных примерах использование using правильнее.
В других местах, где объект является общим для нескольких методов, предпочитаю создать один объект ( содним конекшеном) и использовать его, а не для каждого метода создавать свои объект и новый конекшен.
Предпочитаю делать это сам и наверно это дело привычки, т.к. основное время пишу на Delphi
В других местах, где объект является общим для нескольких методов, предпочитаю создать один объект ( содним конекшеном) и использовать его, а не для каждого метода создавать свои объект и новый конекшен.
По поводу освобождения, мне кажется, что тут у вас не какие то космические расчеты, которые нельзя доверить GC для освобождения памяти.
Предпочитаю делать это сам и наверно это дело привычки, т.к. основное время пишу на Delphi
Sign up to leave a comment.
Облегчаем себе жизнь 2 (Postgresql + asp.net)