Здравствуйте, Ведмедь, Вы писали:
В>Я думаю такой механизм был бы удобным, пока нет нового фреймвока и новой студии... там вроде есть что то подобное.
Вообще-то да... Идеальным решением было бы переписывание дизайнера для датасета, точнее написание своего, со встраиванием туда описания механизма апдейта. Но это дюже много работы и думаю оно того не стоит. Достаточно наверное свой дизайнерский контрол, как ты и говоришь, который будет прикручивать инфу для апдейта к конретному инстансу датасета. Только вот вопрос, кто ж это будет делать?
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, Alexds, Вы писали:
A>>Проблема не в том, чтобы сделать. Просто хочется общего, единого, красивого решения O>А надо ли всё под одну гребенку?
Дык... вся идея этой библиотеки чтобы унифицировать доступ к данным и по возможности отвязаться от провайдера.
O>Так и будет враппер на враппере сидеть и враппером погонять...
В разумных пределах врапперы не мешают, а только лишь помогают. До того момента как они продолжают эффективно решать какую-то проблему и делают код чище, почему бы их и не применять? Пока что здесь еще никто не зашел за эту границу (как мне кажется ).
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, mikа, Вы писали:
M>>Здравствуйте, Ведмедь, Вы писали:
В>>>Я думаю такой механизм был бы удобным, пока нет нового фреймвока и новой студии... там вроде есть что то подобное.
M>>Ну это еще не повод останавливать в развитии это библиотеки. Высокоуровневое над высокоуровневум еще никто не отменял Правда, Игорь?
M>Отвечаю сам себе. Игоря я имел Ткачева. После написания данного поста решил выяснить, а как же по имени товарищ Ведмедь... Вот ведь совпадение!
Тогда я еще на пред пост отвечу. Это не повод отсанавливаться в развитии библиотеки, просто не хочется велосипед изобретать Пока его нет, да удобно сделать А когда появится, тогданадо будет думать
Здравствуйте, Walker, Вы писали:
A>>>Проблема не в том, чтобы сделать. Просто хочется общего, единого, красивого решения O>>А надо ли всё под одну гребенку? W>Дык... вся идея этой библиотеки чтобы унифицировать доступ к данным и по возможности отвязаться от провайдера.
Как бы не это было целью создания SQL Унификация приводит к минимализму и ограничениям. К тому же довольно редко бывает так, что нужно настолько явное отвлечение от провайдера, чтобы ни-ни! А когда у тебя вертится MSSQL не очень-то разумно оставаться в рамках MDB...
Вообще, по моему разумения, в RFD три части:
1. Маппер, на мой взгляд самое ценное
2. Провайдеры, просто фабрика объектов для выполнения запросов
3. DbManager, сущность интеграции первого и второго + много полезных перегрузок для упрощения часто встречающихся задач
Таким образом в RFD нет естественного места для работы со схемами таблиц и прочими сущностями выходящими за рамки выполнения запросов к базе. Собственно, DbManager данными не манипулирует, он их получает от провайдера, пропускает через маппер (если нужно) и отдаёт результат. Накручивание подобной функциональности неизбежно ограничит общность RFD. Другое дело, что в частных задачах это всё нужно, но каждому своё. Поэтому, на мой взгляд, нужно двигаться в сторону получения необходимой информации от маппера (что уже делается), как то аттрибуты, информация о маппинге и всё такое, чтобы кому надо мог бы накрутить сверху то, что ему надо.
O>>Так и будет враппер на враппере сидеть и враппером погонять... W>В разумных пределах врапперы не мешают, а только лишь помогают. До того момента как они продолжают эффективно решать какую-то проблему и делают код чище, почему бы их и не применять? Пока что здесь еще никто не зашел за эту границу (как мне кажется ).
"Введение нового уровня абстракции помогает решить все проблемы, кроме слишком большого количества уровней абстракции"
Здравствуйте, orangy, Вы писали:
O>Таким образом в RFD нет естественного места для работы со схемами таблиц и прочими сущностями выходящими за рамки выполнения запросов к базе. Собственно, DbManager данными не манипулирует, он их получает от провайдера, пропускает через маппер (если нужно) и отдаёт результат. Накручивание подобной функциональности неизбежно ограничит общность RFD. Другое дело, что в частных задачах это всё нужно, но каждому своё. Поэтому, на мой взгляд, нужно двигаться в сторону получения необходимой информации от маппера (что уже делается), как то аттрибуты, информация о маппинге и всё такое, чтобы кому надо мог бы накрутить сверху то, что ему надо.
Это все хорошо и никто не отрицает правильности твоих слов. Но давай вернемся к нашим баранам. Библиотека хороша и красива, но вот незадача — позволяет получить датасет из базы, а обратно его туда закинуть — никак. С этого все и началось. Я дописал эту функциональность, но как-то получилось громоздко, и мне даже наверное самому бы не понравилось, если бы кто-то включил такое в библиотеку, но оно работает, и как минимум 2 человека это уже юзают . Естественно встал вопрос по поводу использования хранимых процедур с этим и вообще определения каким образом апдейтить, вставлять, удалять записи из датасета, да так, чтобы определить это в одном месте и забыть. И если ты почитаешь в соседней ветке, никто и не хочет уже вставлять это в библиотеку, это действительно должен быть еще один уровент абстракции Так что мы по-моему спорим ни о чем
O>>>Так и будет враппер на враппере сидеть и враппером погонять... W>>В разумных пределах врапперы не мешают, а только лишь помогают. До того момента как они продолжают эффективно решать какую-то проблему и делают код чище, почему бы их и не применять? Пока что здесь еще никто не зашел за эту границу (как мне кажется ). O>"Введение нового уровня абстракции помогает решить все проблемы, кроме слишком большого количества уровней абстракции"
Вот это вот по-моему единственно, что тебе не нравится, но насколько я вижу, еще никто не поставил здесть проблемы "слишком большого количества уровней абстракции" И опять же, если есть люди, которые считают, что это нужно и облегчит написание кода, почему бы и нет?
Здравствуйте, Walker, Вы писали:
W>Это все хорошо и никто не отрицает правильности твоих слов. <...> Так что мы по-моему спорим ни о чем
Так я и не спорю Просто выразил своё мнение.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, Walker, Вы писали:
W>>Это все хорошо и никто не отрицает правильности твоих слов. <...> Так что мы по-моему спорим ни о чем O>Так я и не спорю Просто выразил своё мнение.
Ну тогда ты бы лучше выразил свое мнение по той проблеме, что я описал в пред. посте А то я не могу красивого решения найти.
Здравствуйте, Walker, Вы писали:
W>Насколько я понял, IT над этой библиотекой работает совсем в другую сторону, и не думаю, что в свою "официальную" версию будет включать поддержку апдейта датасетов, по крайней мере, по той схеме, как это сделал я, т.к. смотрится это криво как-то, хотя и работает IT, правильно я думаю?
Правильно
W>А вот самому это сделать на своей версии — никаких проблем, это ж минут 15-20 работы от силы. Если у тебя вдруг не получается, могу помочь. Я это сразу не сделал, бо проект, на котором у меня это используется, работает под Access и MySql, а там процедер нема, вот за ненадобностью и не сделал
Даю хинт. От DbManager можно наследоваться.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mikа, Вы писали:
M>>Ну это еще не повод останавливать в развитии это библиотеки. Высокоуровневое над высокоуровневум еще никто не отменял Правда, Игорь?
Правда.
M>Отвечаю сам себе. Игоря я имел Ткачева. После написания данного поста решил выяснить, а как же по имени товарищ Ведмедь... Вот ведь совпадение!
Просто удивительное совпадение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
W>>А вот самому это сделать на своей версии — никаких проблем, это ж минут 15-20 работы от силы. Если у тебя вдруг не получается, могу помочь. Я это сразу не сделал, бо проект, на котором у меня это используется, работает под Access и MySql, а там процедер нема, вот за ненадобностью и не сделал
IT>Даю хинт. От DbManager можно наследоваться.
Да ну?? Не поможет, т.к. чтобы сделать возможность апдейта датасетов (более менее красиво), надо немножко перелопатить твои private и non virtual функции, либо в наследнике переписывать все то, что у тебя уже написано. Ни то, ни другое вроде бы не подходит.
Здравствуйте, Walker, Вы писали:
W>Да ну?? Не поможет, т.к. чтобы сделать возможность апдейта датасетов (более менее красиво), надо немножко перелопатить твои private и non virtual функции, либо в наследнике переписывать все то, что у тебя уже написано. Ни то, ни другое вроде бы не подходит.
Это всё негошиэйтэбл. Нужен только список методов, которые нужно сделать protected.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Alexds, Вы писали:
W>>Насколько я понял, IT над этой библиотекой работает совсем в другую сторону, и не думаю, что в свою "официальную" версию будет включать поддержку апдейта датасетов, по крайней мере, по той схеме, как это сделал я, т.к. смотрится это криво как-то, хотя и работает IT, правильно я думаю?
A>А что IT скажет?
В идеале хотелось бы всё делать в редакторе. Например, создаём Component и накладываем на него неких объектов, которым задаём SQL выражение (SP) и список параметров. Т.е. что-то типа рисование DAL в редакторе. Но пока что-то никаких идей как это сделать.
W>>А вот самому это сделать на своей версии — никаких проблем, это ж минут 15-20 работы от силы. A>Проблема не в том, чтобы сделать. Просто хочется общего, единого, красивого решения
Точно, особенно последнего.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, orangy, Вы писали:
O>Таким образом в RFD нет естественного места для работы со схемами таблиц и прочими сущностями выходящими за рамки выполнения запросов к базе. Собственно, DbManager данными не манипулирует, он их получает от провайдера, пропускает через маппер (если нужно) и отдаёт результат. Накручивание подобной функциональности неизбежно ограничит общность RFD.
Всё верно.
К сожалению, чаще всего получается так, что увлечение безграничной функциональностью и безконтрольное добавление фич пораждает таких монстров, которые, в последствии, разваливаясь, хоронят под своими обломками и их создателей. Я ещё хочу жить
Нет никаких проблем добавить дополнительные фичи согласующиеся с текущей функциональностью. Делать же принципиально новые вещи нужно отдельно. Возможно в рамках пространства имён, но обязательно вне класса DbManager.
O> Другое дело, что в частных задачах это всё нужно, но каждому своё. Поэтому, на мой взгляд, нужно двигаться в сторону получения необходимой информации от маппера (что уже делается), как то аттрибуты, информация о маппинге и всё такое, чтобы кому надо мог бы накрутить сверху то, что ему надо.
На сегодняшний день маппер содержит всё необходимое для поддержки фреймворка реализующего как stateless, так и stateful модель (ПСХПП АВК). Так как и первым и вторым я плотно занимаюсь на работе, то всё что я пока смог придумать сам или что мне подсказано вами маппер уже поддерживает. Дальнейший вполне логичный шаг — написание этих самых фреймворков. Но здесь есть одна проблема. Сколько девелоперов, столько и мнений как он должен выглядеть
Если нам не помогут, то мы тоже никого не пощадим.
Я вот тут подумал. А если сделать что-то типа такого:
using (DbManager db = new DbManager())
{
return db
.InsertCommand(commandType, "COMMAND TEXT")
.UpdateCommand(commandType, "COMMAND TEXT")
.DeleteCommand(commandType, "COMMAND TEXT")
.ExecutePreparedDataSet();
}
Тогда можно будет реиспользовать кучу методов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тогда можно будет реиспользовать кучу методов.
Не совсем я понял идею... Уже существующие методы при любом раскладе будут работать только с одной command. Да и еще же надо параметры указать для каждой command... И чем это отличается от передачи commands как параметров в функцию? Ведь если я вызываю несколько разных методов Execute... то я скорее всего захочу для каждого иметь свои commands и parameters к ним, так что выставление commands отдельно для инстанса DbManager вряд ли даст много пользы. Что-то я не понял, можешь подробнее?
И кстати, я уже наваял наследника для выполнения апдейтов датасетов, но я это делал для версии 1.1 (изменения для класса DbManager минимальны), сейчас надо только слить для версии 1.2. Сегодня-завтра сделаю — посмотришь мой подход.
Здравствуйте, Walker, Вы писали:
W>Здравствуйте, IT, Вы писали:
IT>>Тогда можно будет реиспользовать кучу методов.
W>Не совсем я понял идею... Уже существующие методы при любом раскладе будут работать только с одной command. Да и еще же надо параметры указать для каждой command... И чем это отличается от передачи commands как параметров в функцию? Ведь если я вызываю несколько разных методов Execute... то я скорее всего захочу для каждого иметь свои commands и parameters к ним, так что выставление commands отдельно для инстанса DbManager вряд ли даст много пользы. Что-то я не понял, можешь подробнее? W>И кстати, я уже наваял наследника для выполнения апдейтов датасетов, но я это делал для версии 1.1 (изменения для класса DbManager минимальны), сейчас надо только слить для версии 1.2. Сегодня-завтра сделаю — посмотришь мой подход.
Вообще-то уже сделал. Необходимые изменения в классе DbManager:
1. Command property -> virtual
2. Close() method -> virtual
3. HandleException(Exception ex) method -> protected
4. AttachParameters(IDbCommand command, IDbDataParameter[] commandParameters) method -> protected
5. Для мембера _commandParameters надо реализовать виртуальную пропертю CommandParameters и ВЕЗДЕ по коду (4 места) заменить обращение к _commandParameters на CommandParameters.
Скажи, если есть какие проблемы с этим. И если интересно скажи на какой адрес прислать исходники.
Здравствуйте, Walker, Вы писали:
W>Не совсем я понял идею... Уже существующие методы при любом раскладе будут работать только с одной command. Да и еще же надо параметры указать для каждой command... И чем это отличается от передачи commands как параметров в функцию? Ведь если я вызываю несколько разных методов Execute... то я скорее всего захочу для каждого иметь свои commands и parameters к ним, так что выставление commands отдельно для инстанса DbManager вряд ли даст много пользы. Что-то я не понял, можешь подробнее?
Проблема вот в чём. Например, мы хотим иметь метод возвращающий датасет и принимающий его в качестве параметра. Теперь мы хотим иметь возможность задавть тип команды либо опускать его и для этих двух вариантов ещё задавать парметры или опускать их. Итого 2 варианта передачи датасета и 4 для параметров. В результате нужно написать 8 перекрытий. Если это разделить на 2 метода, то писать нужно 6 методов. Но это для одной команды. А у нас их три. Теперь посчитай сколько у нас получается комбинаций.
Если же вынести задание команд в отдельные методы, то дальше комбинируй сам как хочешь.
using (DbManager db = new DbManager())
{
return db
.InsertCommand("INSERT INTO...", db.CreateParameters(entity))
.UpdateCommand(CommandType.StoredProcedure, "UpdateItem")
.DeleteSp("DeleteItem", db.Parameter("@ID"))
.UpdateDataSet();
}
Придётся конечно запоминать сформированные команды в DbManager, но это уже мелочи.
W>И кстати, я уже наваял наследника для выполнения апдейтов датасетов, но я это делал для версии 1.1 (изменения для класса DbManager минимальны), сейчас надо только слить для версии 1.2. Сегодня-завтра сделаю — посмотришь мой подход.
Давай.
Если нам не помогут, то мы тоже никого не пощадим.
IT>using (DbManager db = new DbManager())
IT>{
IT> return db
IT> .InsertCommand("INSERT INTO...", db.CreateParameters(entity))
IT> .UpdateCommand(CommandType.StoredProcedure, "UpdateItem")
IT> .DeleteSp("DeleteItem", db.Parameter("@ID"))
IT> .UpdateDataSet();
IT>}
IT>
IT>Придётся конечно запоминать сформированные команды в DbManager, но это уже мелочи.
Аааааа... вот ты про что! Ну да, очень даже неплохо получается. Я правда, уже почти думал реализовывать это у себя более классическим методом — с помощью задания класса для описания команды. Т.е. класс содержит текст, тип команды и параметры. Ф-и Update... принимают 3 объекта такого класса (для каждой команды), не хочешь — ставь null. Недостаток в моем подходе — надо каждый раз создавать дополнительный объект (даже 3), который кушает память. В твоем подходе же просто не совсем понятно, почему InsertCommand должна возвращать DbManager . Выбор за автором библиотеки . Кстати, в моем коде уже вся функциональность имеется, чтобы реализовать оба подхода, за час-полтора можно сделать.
W>>И кстати, я уже наваял наследника для выполнения апдейтов датасетов, но я это делал для версии 1.1 (изменения для класса DbManager минимальны), сейчас надо только слить для версии 1.2. Сегодня-завтра сделаю — посмотришь мой подход.
IT>Давай.
).
Если нам не помогут, то мы тоже никого не пощадим.
