Здравствуйте, DuШes, Вы писали:
DШ>я не говорил о проблемах с маппером, я вам уже объяснил, что маппер и дизайнер рассматриваю вместе, возможно поставил вас в заблуждение,и вот собственно невозможность его использования применительно к процедурам для построения схемы является той проблемой, которую пытался обозначить
В этом-то и ошибка маппер и дизайнер вполне себе независимые вещи. Например, маппер можно использовать если у вас есть только датаридер и вы хотите из него получить список объектов. Или сущности генерить не дизайнером, а T4-шаблоном.
L>>не надо менять предмет обсуждения. вы высказались про linq2sql-овский маппер, что он "ужос": L>>
L>+ маппиниг резалтсета хранимой процедуры на объекты.
L>>вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
L>>Что вы тут имели в виду конкретно маппер или все-таки весь linq2sql целиком?
DШ>не знаю как вы, но лично я не отделяю маппер и linq to sql data context designer и рассматриваю их как неделимое целое ...
Зачем их рассматривать вместе? Я этого не понимаю?
DШ>дык вот, маппер для процедур — его нет да в принципе теоретически быть не может, когда речь будет идти о возвращаемом датасете из нескольких таблиц...
не маппер для процедур невозможен, а невозможна генерация типизированного резалтсета для таких процедур.
тем не менее для таких процедур можно вполне успешно использовать маппер, смотри доку по IMultipleResults
DШ>в целом, если вы просто говорите что мол да, маппер свои задачи чисто по маппингу в/из базы/классы выполняет — то да, тут не соглашаться не с чем...это самое простое что есть забиндить поле из таблицы в соотвествующее свойство из класса,
А чего тогда было не него наезжать-то?
DШ>но использовать чисто маппер из всего linq to sql ради только маппера вообще теряет смысл — и на этом давайте закончим наше обсуждение именно маппера, а не в целом linq to sql
Нет, рано заканчивать. Мне надо убедиться, что вы в достаточной мере знаете возможности linq2sql-а (а не только его дизайнера). А там уже и закончим.
DШ>теперь в целом по linq to sql в рамках стартовой темы и применительно использования процедур: мое мнение — смысла использовать сам linqtosql и в том числе и сам его маппер смысла не имеет, если схема строится только на процедурах, более того, в более-менее сложной системе, одно из требований которой скорость обработки данных, использовать linqtosql даже без использования процедур тоже не имеет смысла
Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, gandjustas, Вы писали:
G>> В этом конкретном случае видимно никто и не собирался залить в процедуры для оптимизации, обычно их применяют только для инкапсуляции, view в этом плане гороздо выгоднее. IB>Проблема в том, что можно доинкапсулироваться до полной потери производительности.
Сделать хреново можно и с ХП.
G>>ИМХО нет разницы править 4 процедуры или вьюху и 3 триггера. IB>Править нет. А вот когда нужно понять что происходит или что-то поменять с предсказуемым результатом — процедуры рулят.
Это относительно. Я уже вполне привык работать с вьюхами и триггерами.
Главное чтобы каши не было, если делать, то все одинаково.
Здравствуйте, Tom, Вы писали:
G>>производительность системы — да, производительность программистов от этого сильно уменьшится. Tom>А можно аргументы?
Ну это вроде как очевидно.
Текстовые запросы тяжелее писать\пожжерживать, чем Linq, кроме того на каждое изменение выборки придется модифицировать целевую БД.
Здравствуйте, Lloyd, Вы писали:
L>В этом-то и ошибка маппер и дизайнер вполне себе независимые вещи. Например, маппер можно использовать если у вас есть только датаридер и вы хотите из него получить список объектов. Или сущности генерить не дизайнером, а T4-шаблоном. L>Зачем их рассматривать вместе? Я этого не понимаю? L>А чего тогда было не него наезжать-то?
такое ощущение, что у вас свой linqtosql и работаете вы не используя datacontext...
никто не наезжал на маппер, маппер в вашем понимании и самое понятие маппинг разные вещи, вы видимо говорите об определенных классах из system.data.linq, я же говорю о самом процессе организации связи данных из процедуры на свойства сгенерированных в схеме классов, и в данном случае преимуществ нет от использования linqtosql по сравнению с классическим использование Datareader и использованием рефлексии или же вы просто не можете их показать
L>Нет, рано заканчивать. Мне надо убедиться, что вы в достаточной мере знаете возможности linq2sql-а (а не только его дизайнера). А там уже и закончим.
Какие возможности, о чем вы говорите сейчас? об использовании IQueriable, об использовании system.data.linq.mapping? в чем вам надо убедиться, в том что вы взяли за основу классы из linqtosql, затачиваете их вручную путем кодирования классов под себя и считаете что используете в полной мере linqtosql — ну наверно в данном контексте можно сказать что используете, только стоило ли оно того? хотя бы сценарии использования чтоли приведите, в ыработаете через сгенерированный datacontext или же просто используете классы cfvjuj linqtosql, по сути реализовав свою сотственную реализацию DAL? ведь суть применения linqtosql и состояла, может я конечно и заблуждаюсь, чтобы максимально отодвинуть программиста от разработки этого слоя и использования сразу классов бизнесс-логики или нет?
L>Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли?
времени мне своего не жалко, потому что такого рода orm мапперы пишутся за час, и широко используются ... вот только в качестве основного преимущества использоания linq-вского маппинга почему то считается именно сам дизайнер...
Здравствуйте, DuШes, Вы писали:
L>>В этом-то и ошибка маппер и дизайнер вполне себе независимые вещи. Например, маппер можно использовать если у вас есть только датаридер и вы хотите из него получить список объектов. Или сущности генерить не дизайнером, а T4-шаблоном. L>>Зачем их рассматривать вместе? Я этого не понимаю? L>>А чего тогда было не него наезжать-то?
DШ>такое ощущение, что у вас свой linqtosql и работаете вы не используя datacontext...
Linq2Sql у меня ровно тот же, что и у всех остальных.
DШ>никто не наезжал на маппер, маппер в вашем понимании и самое понятие маппинг разные вещи, вы видимо говорите об определенных классах из system.data.linq, я же говорю о самом процессе организации связи данных из процедуры на свойства сгенерированных в схеме классов, и в данном случае преимуществ нет от использования linqtosql по сравнению с классическим использование Datareader и использованием рефлексии или же вы просто не можете их показать
Я привел эти преимущства выше по ветке в виде списка. Преимуществ же речного маппинга или самописного маппинга через refelection вы почему-то не привели. Где они?
L>>Нет, рано заканчивать. Мне надо убедиться, что вы в достаточной мере знаете возможности linq2sql-а (а не только его дизайнера). А там уже и закончим. DШ>Какие возможности, о чем вы говорите сейчас? об использовании IQueriable, об использовании system.data.linq.mapping? в чем вам надо убедиться, в том что вы взяли за основу классы из linqtosql, затачиваете их вручную путем кодирования классов под себя и считаете что используете в полной мере linqtosql — ну наверно в данном контексте можно сказать что используете, только стоило ли оно того? хотя бы сценарии использования чтоли приведите, в ыработаете через сгенерированный datacontext или же просто используете классы cfvjuj linqtosql, по сути реализовав свою сотственную реализацию DAL? ведь суть применения linqtosql и состояла, может я конечно и заблуждаюсь, чтобы максимально отодвинуть программиста от разработки этого слоя и использования сразу классов бизнесс-логики или нет?
Что за привычка съезжать в сторону. Мы обсуждаем не мои способы работы, а недостатки linq2sql-а, с которыми вы сталкиваетесь. Давайте закончим с обсуждением маппинга процедур, возвращающих несколько резалтсетов. А потом перейдем на длюбые другие интересующие вас темы. Ок?
L>>Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли? DШ>времени мне своего не жалко, потому что такого рода orm мапперы пишутся за час, и широко используются ... вот только в качестве основного преимущества использоания linq-вского маппинга почему то считается именно сам дизайнер...
Почему вы так выбрасываете ответы на вопросы, которые вы ставили? Вам чем-то не удовлетворил предложенный IMultipleResults?
Здравствуйте, Lloyd, Вы писали:
L>Я привел эти преимущства выше по ветке в виде списка. Преимуществ же речного маппинга или самописного маппинга через refelection вы почему-то не привели. Где они?
вы их спрашивали?
те преимущества, которые вы привели:
1. Он есть
2. качественно оттестирован толпой тестеров в микрософте
3. по нему есть документация
4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
вот эти? вам самому не смешно?
Почему вы выбрасываете или просто игнорируете мои ответы? я повторюсь, то что вы заточили классы linq под себя, имеет право на существование, но не дает ровно никаких преимуществ...
L>Почему вы так выбрасываете ответы на вопросы, которые вы ставили? Вам чем-то не удовлетворил предложенный IMultipleResults?
никто в сторону не съезжал все о чем вы говорите это и есть напильник и по сути свой уже самописный dal, ну давайте здраво рассуждать, внесение изменений в сгенерированные классы, написание своих кастомных классов для обертки результатов процедур, трекинг вручную, ну давайте сюда впишем реализацию IMultipleResults для датасетов — вы считаете, что это дало вам преимущество какое-то? вы не написали свой слой для работы с базой? это вам так реально помогает и уменьшает трудозатраты?
задача linqtosql была в первую очередь генерация классов на основе предложенной схемы базы данных, он должен был забрать на себя эти обязанности, не вы...
Re[20]: LINQ vs Store Procedure
От:
Аноним
Дата:
19.03.09 19:55
Оценка:
Здравствуйте, DuШes, Вы писали:
DШ>задача linqtosql была в первую очередь генерация классов на основе предложенной схемы базы данных, он должен был забрать на себя эти обязанности, не вы...
imho дизайнер (генератор классов, маппинга) это мизер в linq2sql, хоть он и позволяет быстро что-то сделать.
в nhibernate вообще этого нет, есть простенький тул по генерации простых классов-шаблонов по схеме маппинга, но многие считают что это неплохой ORM.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, DuШes, Вы писали:
DШ>>задача linqtosql была в первую очередь генерация классов на основе предложенной схемы базы данных, он должен был забрать на себя эти обязанности, не вы...
А>imho дизайнер (генератор классов, маппинга) это мизер в linq2sql, хоть он и позволяет быстро что-то сделать. А>в nhibernate вообще этого нет, есть простенький тул по генерации простых классов-шаблонов по схеме маппинга, но многие считают что это неплохой ORM.
если вкратце, скажем, есть задача по созданию dal, в рамках обсуждения считаем, что используем процедуры (не напрямую таблицы), что мне предлагает linqtosql:
1. написать класс логики, который будет являться отображением полей из возвращаемого набора нашей процедуры
2. атрибутивно показать, какое поле из рекордсета в какое свойство моего класса маппится
3. ну и ручной трекинг через аксессоры
вручную:
1. без изменения
2. получаю datareader, вручную заполняю нужные мне свойства
3. без изменения
все операции по удалению, сохранению сводятся по сути к вызову процедуры что в первом что во втором случае...
в случае прямого маппинга из таблиц на классы — тут преимущество налицо, полная мощь генератора, пара секунд и все классы сгенерированы, спорить не очем..один минус — нет обратной связи из классов в структуру базы, скажем, в devexpress xpo это есть, и не нужно задумываться о ручном добавлении поля обратно в базу
я не спорю, linqtosql очень мощный инструмент и для определенного круга задач его использование более чем оправдано, но когда дело доходит до чуть более сложных схем маппинга, возникают трудозатраты, сравнимые с написанием своего собственного dal...
Здравствуйте, DuШes, Вы писали:
L>>Я привел эти преимущства выше по ветке в виде списка. Преимуществ же речного маппинга или самописного маппинга через refelection вы почему-то не привели. Где они?
DШ>вы их спрашивали?
Считайте, что спрашиваю сейчас.
DШ>те преимущества, которые вы привели: DШ>
DШ>1. Он есть
DШ>2. качественно оттестирован толпой тестеров в микрософте
DШ>3. по нему есть документация
DШ>4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
DШ>вот эти? вам самому не смешно?
Нет, ничуть. Я ведь не знаю функциональности вашего маппера, поэтому не могу в качестве преимуществ приводить функциональность, приходится ограничиваться теми, по которым самописный код по-любому проигрывает. Если приведете описание функционала вашего маппера, тогда можно будет сравнивать их.
DШ>Почему вы выбрасываете или просто игнорируете мои ответы?
Извините, если это действительно произошло. Если я что-то пропустил, укажите что именно, по возможности постараюсь исправить эту ошибку
DШ>я повторюсь, то что вы заточили классы linq под себя, имеет право на существование, но не дает ровно никаких преимуществ...
Я не затачивал классы linq2sql под себя, совсем не затачивал. С чего вы взяли, что я что-то где-либо затачивал?
L>>Почему вы так выбрасываете ответы на вопросы, которые вы ставили? Вам чем-то не удовлетворил предложенный IMultipleResults?
DШ>никто в сторону не съезжал все о чем вы говорите это и есть напильник и по сути свой уже самописный dal, ну давайте здраво рассуждать, внесение изменений в сгенерированные классы,
Ссылку, ни о каких внесениях изменений я не писал, даже в мыслях не было.
DШ>написание своих кастомных классов для обертки результатов процедур,
Совсем не обязательно писать эту обертку, если считаете, что она не нужна. Просто почитайте что такое IMultipleResults. И вопросы отпадут сами собой.
DШ>трекинг вручную,
Опять же, ссылку
DШ>ну давайте сюда впишем реализацию IMultipleResults для датасетов
Во-первых, не "для датасетов", а "для процедур возвращающих несколько резалтсетов"
А во-вторых, не реализация, а использование функционала, который уже входит в состав linq2sql, в том числе имеется поддержка со стороны дизайнера.
DШ>- вы считаете, что это дало вам преимущество какое-то? вы не написали свой слой для работы с базой? это вам так реально помогает и уменьшает трудозатраты?
Не написал ни строчки, в том-то и фишка. Весь функционал идет из коробки.
DШ>задача linqtosql была в первую очередь генерация классов на основе предложенной схемы базы данных, он должен был забрать на себя эти обязанности, не вы...
Это вообще ни разу не задача Linq2Sql — это задача дизайнера Linq2Sql, не надо путать эти две вещи, а то вы так докатетесь до того, что станете утверждать, что то, что генерит тот же SQLMetal — это не Linq2Sql
Здравствуйте, DuШes, Вы писали:
DШ>если вкратце, скажем, есть задача по созданию dal, в рамках обсуждения считаем, что используем процедуры (не напрямую таблицы), что мне предлагает linqtosql: DШ>1. написать класс логики, который будет являться отображением полей из возвращаемого набора нашей процедуры
не класс логики, а даных и не написать, а воспользоваться дизайнером.
DШ>2. атрибутивно показать, какое поле из рекордсета в какое свойство моего класса маппится
Нужно, но опять же в дизайнере.
DШ>3. ну и ручной трекинг через аксессоры
Никакого ручного трекинга. Дизайнер сгенерит нужный код сам.
DШ>вручную: DШ>1. без изменения
Не совсем (см. выше).
DШ>2. получаю datareader, вручную заполняю нужные мне свойства DШ>3. без изменения
Не совсем (см. выше).
DШ>все операции по удалению, сохранению сводятся по сути к вызову процедуры что в первом что во втором случае...
Не совсем. В первом способе ты сможешь в дизайнере указать INSERT/UPDATE/DELETE-процедуры для созданного класса данных и переложить функционал по вызову этих процедур на плечи Linq2Sql-а. С твоей стороны вся работа сведется к вызову context.SubmitChanges()
DШ>в случае прямого маппинга из таблиц на классы — тут преимущество налицо, полная мощь генератора, пара секунд и все классы сгенерированы, спорить не очем..один минус — нет обратной связи из классов в структуру базы, скажем, в devexpress xpo это есть, и не нужно задумываться о ручном добавлении поля обратно в базу
Этот недостаток имеется, но при должной дисциплине разработки с ним можно жить. Лучше бы его не было, но что делать.
DШ>я не спорю, linqtosql очень мощный инструмент и для определенного круга задач его использование более чем оправдано, но когда дело доходит до чуть более сложных схем маппинга, возникают трудозатраты, сравнимые с написанием своего собственного dal...
еще раз, как я понимал, беседа изначально велась в конктексте использования процелур в рамках linqtosql, собственно и тема так называется, я пытался вам доказать, что если речь идет о переходе на использование процедур, то смысла применять linqtosql просто нет, а стоит задуматься о написании своей orm или рассматривать другие решения, о минусах и плюсах самого linqtosql вроде бы тоже говорили..
L>>>Я привел эти преимущства выше по ветке в виде списка. Преимуществ же речного маппинга или самописного маппинга через refelection вы почему-то не привели. Где они? DШ>>вы их спрашивали? L>Считайте, что спрашиваю сейчас.
ну как минимум обратное отображение в базу данных, в идеале я вообще не должен вносить изменений в базе, если уж использовать некую orm, то вообще на задумываясь о структуре базы, это есть и задача полноценной orm, и полноценный трекинг, лишенный вероятности прости физически забыть дернуть событие из аксессоров...
DШ>>те преимущества, которые вы привели: DШ>>
DШ>>1. Он есть
DШ>>2. качественно оттестирован толпой тестеров в микрософте
DШ>>3. по нему есть документация
DШ>>4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
DШ>>вот эти? вам самому не смешно? L>Нет, ничуть. Я ведь не знаю функциональности вашего маппера, поэтому не могу в качестве преимуществ приводить функциональность, приходится ограничиваться теми, по которым самописный код по-любому проигрывает. Если приведете описание функционала вашего маппера, тогда можно будет сравнивать их.
в качестве преимущества вы приводите то что он есть? есть документация? не спорю, наверно это действительно сильные стороны...свои доводы в пользу написания своего mapping dal привел выше
Задумываться об этом действительно не стоит, т.к. эту проблему вполне себе решает Linq2Sql-овский дизайнер.
...
Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
...
Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
...
...
теперь в целом по linq to sql в рамках стартовой темы и применительно использования процедур: мое мнение — смысла использовать сам linqtosql и в том числе и сам его маппер смысла не имеет, если схема строится только на процедурах, более того, в более-менее сложной системе, одно из требований которой скорость обработки данных, использовать linqtosql даже без использования процедур тоже не имеет смысла
Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли?
где я писал, что пишется все руками?
если вернемся в начало, то началось все с данного моего ответа, собственно я остался пока при своем мнении о наличии "ужоса" в процессе как разработки так и сопровождения схемы на основе процедур
L>+ маппиниг резалтсета хранимой процедуры на объекты.
вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
к тому же, самое плохое в linq to sql это то, что нет обратного маппинга из классов схемы в базу данных...в том же самом DX XPO эта проблема решена (не сочтите за рекламу )
еще раз, те минусы которые я увидел:
нужно свойство — добавляем поле в таблицу, обеспечиваем синхронизацию путем выставления атрибутов, вносим код для трекинга в аксессоры, и это мы еще не рассматривали варианты, когда меняется тип данных...причем процесс контролируется только разработчиком, представляю себе сложности, которые могут возникнуть в случае необходимости поддержания версионности базы данных..
для процедур вообще ручное кодирование классов-врапперов и необходимоть поддержания как самого кода процедуры, так и самого класса в синхронном состоянии, потому что ну нет возможности отселдить изменения в коде процедуры и наложить их обратно на класс не говоря уж об обратном процессе..
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Tom, Вы писали:
G>>>производительность системы — да, производительность программистов от этого сильно уменьшится. Tom>>А можно аргументы? G>Ну это вроде как очевидно. G>Текстовые запросы тяжелее писать\пожжерживать, чем Linq, кроме того на каждое изменение выборки придется модифицировать целевую БД.
В упор непонимаю почему запросы SQL тяжелее писать чем LINQ. Как раз SQL (TSQL) обладает всей мощью для работы с БД, в отличии от линка.
Ну и второй аргумент вообще непонятен. зачем целевую БД модифицировать, почему, непонятно....
L>Совсем не обязательно. Мы на одном проекте использовали типизированые обертки над хранимками (свой кастом тул), внутри которого вполне себе удачно использовался ADO.NET
Ну и правильно, кастом тул я не рассматривал.вариант с кастом тулом который строит враперы над сторами и запросами вообще нравится больше линка.
J>>>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы? Tom>>останется compile time проверки вызова стор. J>Скорее строго-типизированная обертка, чем полноценная проверка. Проверять что параметры хранимке переданы правильно, оно не будет. И даже что она на самом деле есть в базе — не проверит.
Строго типизированная обёртка как раз и есть то, что ОЧЕНЬ необходимо при работе с БД. По поводу того, что на самом деле есть в базе — это вопрос того как устроен билд. Если у вас линк related код генерится в ходе билда, а не один раз статически из студии, то у вас очень хорошая гарантия что ваш C# синхронизирован с БД.
J>Я имел ввиду что перенос сгенеренных линкой запросов в хранимки не даст прироста. Но можно и переписать все, конечно, с полной уверенностью что "уж я-то шарю в базах, уж я-то всяко сделаю быстрее, чем тупой генератор". Но это обратно по поводу самодуров и кретинов. Далеко не факт что это даст прирост чистыми (см. "преждевременная оптимизация" и "5% кода занимают 95% времени").
Не надо называть всех идиотами, критинами и самодурами. Это не добавляет сообщениям смысла.
Тупой генератор, может сгенерировать человеческий запрос для простых случаев. В реальных системах, когда запросы становятся сложными, написать их на линке вообще невозможно, а тем более написать их оптимально. TSQL развивался десятилетиями и специально заточен для работы с бд. Вот и используете его для работы с БД. А хранимки для того, что бы эти сложные операции/запросы оптимизировать и поддерживать.
Tom>>Работать с хранимкапми на порядок удобнее, намного проще например отлаживать план выполнения. J>Работать с ассемблером тоже было бы удобнее, если бы все занимались исключительно оптимизацией. J>Минусов у хранимок навалом. Мне они очевидны и здесь сто раз уже обсуждались. Расписать основные?
Распиши конечно
L>Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
О, а можно пару слов, про процедуру внесения изменений в схему?
TK>Почитайте тут: http://msdn.microsoft.com/ru-ru/library/ms181055.aspx TK>В остальном, надо исходить из того, что SQL Server хранит только исходный код хранимых процедур и триггеров. При выполнении хранимой процедуры или триггера в первый раз исходный код компилируется в план выполнения. т.е. разница только в том, где будет хранится "текст" запросов. в случае с хранимыми процедурами (особенно если их тысячи) вы "усложняете" себе поддержку вашего решения.
По сабжу. Ado.NET Team продолжает традиции МС в разработке фреймворков для доступа к данным: вместо того, чтобы довести хоть одну технологию до ума, они вечно бросаются из крайности в крайность — то у нас рулит disconnected approach и датасеты, то нифига, бизнесь не выживет без ормапперов с поддержкой наследования и статически верифицируемых запросов к СУБД.
Если не секрет, о каких типах приложений вы спорите? И EF, И Linq2Sql неудобны для написания data-driven desktop clients по куче причин. Во-первых отсутствие disconnected-режима (только давайте не будем говорить про Sql Compact и репликацию с главным сервером — это разные сценарии). Во-вторых — грабли с биндингом, загрузкой графа объектов и регистрацией их в контексте (особенно через хранимки). В третьих — невозможность глобальной валидации на уровне контекста. Либо работаем исключительно через воспомогательные методы (биндинг идёт лесом), либо смиряемся с тем, что некорректные данные обнаруживаются только сервером при submit changes. Я говорю не о тривиальных проверках, которые вполне осуществимы через геттеры/сеттеры, а о проверках, которые необходимо делать при изменении контекста (эдакий аналог событий RowChanging у DataTable).
Здравствуйте, DuШes, Вы писали:
DШ>еще раз, как я понимал, беседа изначально велась в конктексте использования процелур в рамках linqtosql, собственно и тема так называется, я пытался вам доказать, что если речь идет о переходе на использование процедур, то смысла применять linqtosql просто нет, а стоит задуматься о написании своей orm или рассматривать другие решения, о минусах и плюсах самого linqtosql вроде бы тоже говорили..
L>>>>Я привел эти преимущства выше по ветке в виде списка. Преимуществ же речного маппинга или самописного маппинга через refelection вы почему-то не привели. Где они? DШ>>>вы их спрашивали? L>>Считайте, что спрашиваю сейчас.
DШ>ну как минимум обратное отображение в базу данных, в идеале я вообще не должен вносить изменений в базе, если уж использовать некую orm, то вообще на задумываясь о структуре базы, это есть и задача полноценной orm, и полноценный трекинг, лишенный вероятности прости физически забыть дернуть событие из аксессоров...
Вариант с Linq2Sql-м + сущности сгенерированные дизайнером отвечает этим критериям.
DШ>>>те преимущества, которые вы привели: DШ>>>
DШ>>>1. Он есть
DШ>>>2. качественно оттестирован толпой тестеров в микрософте
DШ>>>3. по нему есть документация
DШ>>>4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
DШ>>>вот эти? вам самому не смешно? L>>Нет, ничуть. Я ведь не знаю функциональности вашего маппера, поэтому не могу в качестве преимуществ приводить функциональность, приходится ограничиваться теми, по которым самописный код по-любому проигрывает. Если приведете описание функционала вашего маппера, тогда можно будет сравнивать их.
DШ>в качестве преимущества вы приводите то что он есть? есть документация? не спорю, наверно это действительно сильные стороны...
То, что вы описали, уже есть в Linq2Sql, так что необходимости-таки нет.
DШ>свои доводы в пользу написания своего mapping dal привел выше
нет, выше вы привели доводы по поводу того, что вы считаете "полноценной orm". не подменяйте понятия. перечитывайте ответ перед тем как нажать "Отправить"
DШ>
DШ>Задумываться об этом действительно не стоит, т.к. эту проблему вполне себе решает Linq2Sql-овский дизайнер.
DШ>...
DШ>Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
DШ>...
DШ>Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
DШ>...
DШ>...
DШ>теперь в целом по linq to sql в рамках стартовой темы и применительно использования процедур: мое мнение — смысла использовать сам linqtosql и в том числе и сам его маппер смысла не имеет, если схема строится только на процедурах, более того, в более-менее сложной системе, одно из требований которой скорость обработки данных, использовать linqtosql даже без использования процедур тоже не имеет смысла
DШ>Только потому что дизайнер что-то не поддерживает, вы пишите все руками? Времени своего не жалко что-ли?
DШ>где я писал, что пишется все руками?
DШ>если вернемся в начало, то началось все с данного моего ответа, собственно я остался пока при своем мнении о наличии "ужоса" в процессе как разработки так и сопровождения схемы на основе процедур
Я понял, что вы остались при своем мнении, но не понял почему
DШ>
L>>+ маппиниг резалтсета хранимой процедуры на объекты.
DШ>вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
DШ>к тому же, самое плохое в linq to sql это то, что нет обратного маппинга из классов схемы в базу данных...в том же самом DX XPO эта проблема решена (не сочтите за рекламу )
DШ>еще раз, те минусы которые я увидел: DШ>нужно свойство — добавляем поле в таблицу, обеспечиваем синхронизацию путем выставления атрибутов, вносим код для трекинга в аксессоры, и это мы еще не рассматривали варианты, когда меняется тип данных...
Нет, не совсем так. Добавляем поле в дизайнере, нажимаем Save. Все, алгоритм закончился. При изменении типа все ровно то же самое.
DШ>причем процесс контролируется только разработчиком, представляю себе сложности, которые могут возникнуть в случае необходимости поддержания версионности базы данных..
Это понятия ортогональное к Linq2Sql-у, версионность базы тут никак не повлияет.
DШ>для процедур вообще ручное кодирование классов-врапперов и необходимоть поддержания как самого кода процедуры, так и самого класса в синхронном состоянии, потому что ну нет возможности отселдить изменения в коде процедуры и наложить их обратно на класс не говоря уж об обратном процессе..
Ровно то же самое вы будете делать и в своем продходе. Но в вашем подходе вам еще придется реализовывать маппинг. Где обещанное преимущество?
P.S. В своем предыдущем сообщении я попросил привести ссылки на мои сообщения, где я якобы: предлагал вручную менять сгенерированный код и реализовывать трекинг вручную. Не могли бы вы потрудиться и все-таки найти сообщения, где я все это предлагал? Спасибо.
Здравствуйте, Tom, Вы писали:
L>>Совсем не обязательно. Мы на одном проекте использовали типизированые обертки над хранимками (свой кастом тул), внутри которого вполне себе удачно использовался ADO.NET Tom>Ну и правильно, кастом тул я не рассматривал.вариант с кастом тулом который строит враперы над сторами и запросами вообще нравится больше линка.
Нет, этот вариант хуже линка, уверяю вас. Маппинг придется реализовывать в ручную. Хотя кому-то это очень нравится (DuШes).
Здравствуйте, Tom, Вы писали:
Tom>А в чём усложнение?
В том, что все запросы из кода надо каким-то неочевидным способом оборачивать в хранимки. Я не знаю готовых инструментов для этого. И даже с использованием инструментов считаю это излишним усложнением. При поддержке придется вместо linq запроса в коде править хранимку, какой выигрыш мы получаем от линка в данной ситуации? Также усложняем контроль версий или деплоинг приложения.
все о чем вы говорите это и есть напильник и по сути свой уже самописный dal, ну давайте здраво рассуждать, внесение изменений в сгенерированные классы, написание своих кастомных классов для обертки результатов процедур, трекинг вручную, ну давайте сюда впишем реализацию IMultipleResults для датасетов — вы считаете, что это дало вам преимущество какое-то? вы не написали свой слой для работы с базой? это вам так реально помогает и уменьшает трудозатраты? 
