Здравствуйте, Tom, Вы писали:
J>>Если все это правда, то твой шеф — кретин. По совокупности следующих пунктов: Tom>Я бы на вашем месте не был так котегоричен.
А почему бы не был? Почему бы шефу не являться кретином, и почему бы мне это здесь не констатировать?
J>>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы? Tom>останется compile time проверки вызова стор.
Скорее строго-типизированная обертка, чем полноценная проверка. Проверять что параметры хранимке переданы правильно, оно не будет. И даже что она на самом деле есть в базе — не проверит.
От LINQ еще многое останется, на самом деле. Я просто хотел напомнить что LINQ в этой технологии все-таки ключевой элемент.
J>>2. Запросы компилируются и скорости перенос тех же самых запросов в хранимки не добавит. Это известный факт. Tom>Разница огромна, при использовании линка запросы SQL генерит линк, при использовании явных запросов или стор — вы сами.
Я имел ввиду что перенос сгенеренных линкой запросов в хранимки не даст прироста. Но можно и переписать все, конечно, с полной уверенностью что "уж я-то шарю в базах, уж я-то всяко сделаю быстрее, чем тупой генератор". Но это обратно по поводу самодуров и кретинов. Далеко не факт что это даст прирост чистыми (см. "преждевременная оптимизация" и "5% кода занимают 95% времени").
Tom>Работать с хранимкапми на порядок удобнее, намного проще например отлаживать план выполнения.
Работать с ассемблером тоже было бы удобнее, если бы все занимались исключительно оптимизацией.
Минусов у хранимок навалом. Мне они очевидны и здесь сто раз уже обсуждались. Расписать основные?
Tom>найти узкое место — это действительно надо в первую очередь.
Нужно было это поставить первым и единственным пунктом. Остальные аргументы — до кучи, и, если копнуть поглубже, действительно могут быть спорны.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Jakobz, Вы писали:
J>>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы?
L>+ маппиниг резалтсета хранимой процедуры на объекты.
вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
к тому же, самое плохое в linq to sql это то, что нет обратного маппинга из классов схемы в базу данных...в том же самом DX XPO эта проблема решена (не сочтите за рекламу )
L>+ tracking изменений
tracking изменений — где его вы видели, дерганье методов/событий из акксосоров свойств? ну если это имеете ввиду, то это совсем не трекинг
Здравствуйте, DuШes, Вы писали:
J>>>1. LINQ to SQL, завязаный только на хранимые процедуры — это "LINQ to SQL" без слова "LINQ". Что там собственно останется-то хорошего, если оттуда убрать запросы?
L>>+ маппиниг резалтсета хранимой процедуры на объекты.
DШ>вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
как тебе поможет его отсутствие "когда придется расширять классы или структуру таблиц"
L>>+ tracking изменений DШ>tracking изменений — где его вы видели, дерганье методов/событий из акксосоров свойств?
Нет, я имел в виду, что datacontext отслеживает изменения, произведенные над сущностью, и по SubmitChanes сливает их в базу.
Реализуется это действительно через привязку к соответствующим событиям, но это не единственный вариант.
DШ>ну если это имеете ввиду, то это совсем не трекинг
L>>>+ маппиниг резалтсета хранимой процедуры на объекты.
DШ>>вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
L>как тебе поможет его отсутствие "когда придется расширять классы или структуру таблиц"
не поможет, но и не помешает — а если не будет смысла его использования, зачем он будет вообще нужен...
т.е. речь о чем? есть результат хранимой процедуры, возвращаю два поля, name & id, мне нужно будет создать класс-враппер для этих получаемых данных, пометить их определенными атрибутами и в принципе начать использовать...расширяю выборку, нужно возвращать уже три поля, скажем добавилось lastname, меняю в процедуре, меняю враппер...
это если бы стали использовать методы/процедуры в linq
классическая схема — тот же самый класс по сути враппер над данными, datareader, ну и ручное кодирование — строка this.lastname = datareader.read(...)
трудозатраты по сути такие же, более того, можно за час работы написать свой orm враппер класс, который по имени свойства из класса сопоставит соотвествующее поле из выборки ...не в этом дело, просто пытаюсь доказать, что в данном случае, когда будут применяться процедуры в линке, необходимость в нем вообще отпадает
L>А что такое по-вашему трекинг?
ну уж по крайне мере не так, уж лучше через аспекты
Здравствуйте, Spender, Вы писали:
S>Здравствуйте, Jakobz, Вы писали:
J>>4. И самое главное: совершенное самодурство и кретинизм делать что-то потому что "я думаю что так будет быстрее". Промерить не судьба? Может у вас там где-нибудь StringBuilder поставить нужно вместо string += и все летать начнет? И переписывать ничего не нужно будет? Может быть есть только один тормозной запрос и его стоит вынуть и оптимизировать, вместо того, чтобы делать это для всех подряд? Если делается расчет на будущее — может стоит сначала написать нагрузочные тесты?
S>Может я телефончик его дам, Вы ему тоже это скажете. Наша команда замудохалась объяснять ему это. Нагрузочные тесты у нас выглядят так. Берутся все программисты и начинают тыкать по кнопочкам, в это время смотрится загрузка SQL сервера.
Здравствуйте, DuШes, Вы писали:
DШ>классическая схема — тот же самый класс по сути враппер над данными, datareader, ну и ручное кодирование — строка this.lastname = datareader.read(...) DШ>трудозатраты по сути такие же,
Какие тогда притензии к стандартному мапперу? Озвучь, пожалуйста.
DШ>более того, можно за час работы написать свой orm враппер класс, который по имени свойства из класса сопоставит соотвествующее поле из выборки ...не в этом дело, просто пытаюсь доказать, что в данном случае, когда будут применяться процедуры в линке, необходимость в нем вообще отпадает
Зачем что-то писать, если это уже есть в составе Linq2Sql
L>>А что такое по-вашему трекинг?
DШ>ну уж по крайне мере не так, уж лучше через аспекты
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, DuШes, Вы писали:
DШ>>классическая схема — тот же самый класс по сути враппер над данными, datareader, ну и ручное кодирование — строка this.lastname = datareader.read(...) DШ>>трудозатраты по сути такие же,
L>Какие тогда притензии к стандартному мапперу? Озвучь, пожалуйста.
прежде чем озвучивать свои претензии я не услышал вашего мнения о преимуществах использования "стандартного" маппера
DШ>>более того, можно за час работы написать свой orm враппер класс, который по имени свойства из класса сопоставит соотвествующее поле из выборки ...не в этом дело, просто пытаюсь доказать, что в данном случае, когда будут применяться процедуры в линке, необходимость в нем вообще отпадает
L>Зачем что-то писать, если это уже есть в составе Linq2Sql
вместе с напильником...
L>>>А что такое по-вашему трекинг?
DШ>>ну уж по крайне мере не так, уж лучше через аспекты
L>Чем лучше?
ну по крайне мере хотя бы тем, что не нужно ВООБЩЕ задумываться о включении какой-либо логики в свойства, я уж не спрашиваю вас о том, как вы сделайте трекинг полей/вызовов методов без аспектов
Здравствуйте, DuШes, Вы писали:
DШ>>>классическая схема — тот же самый класс по сути враппер над данными, datareader, ну и ручное кодирование — строка this.lastname = datareader.read(...) DШ>>>трудозатраты по сути такие же,
L>>Какие тогда притензии к стандартному мапперу? Озвучь, пожалуйста.
DШ>прежде чем озвучивать свои претензии я не услышал вашего мнения о преимуществах использования "стандартного" маппера
Он есть
качественно оттестирован толпой тестеров в микрософте
по нему есть документация
если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
DШ>>>более того, можно за час работы написать свой orm враппер класс, который по имени свойства из класса сопоставит соотвествующее поле из выборки ...не в этом дело, просто пытаюсь доказать, что в данном случае, когда будут применяться процедуры в линке, необходимость в нем вообще отпадает
L>>Зачем что-то писать, если это уже есть в составе Linq2Sql
DШ>вместе с напильником...
Что "вместе с напильником"?
L>>>>А что такое по-вашему трекинг?
DШ>>>ну уж по крайне мере не так, уж лучше через аспекты
L>>Чем лучше?
DШ>ну по крайне мере хотя бы тем, что не нужно ВООБЩЕ задумываться о включении какой-либо логики в свойства,
Задумываться об этом действительно не стоит, т.к. эту проблему вполне себе решает Linq2Sql-овский дизайнер.
DШ>я уж не спрашиваю вас о том, как вы сделайте трекинг полей/вызовов методов без аспектов
Это worst practise — работать с полями напрямую при наличии соответствующих свойств.
Я в свою очередь спрошу как вы собрались делать трекинг полей через аспекты, если я захочу работать с ними через reflection
Здравствуйте, kenzo_u, Вы писали:
_>А может лучше все запросы держать в одном месте? Либо только в виде ХП, либо только в коде программы в DAL-слое?
Если есть DAL, то где конкретно находятся запросы для квалифицированного разработчика — фиолетово. Для стажеров — жестко, только хранимки.
L> L>Он есть L>качественно оттестирован толпой тестеров в микрософте
настолько качественно, что забыли обратный маппинг в базу
L>по нему есть документация L>если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
да, эти люди начинают такие темы, в которой мы сейчас и присутствуем L>
вообщем, linq to sql (именно to sql) насктолько хорош, насколько его благополучно похоронили
DШ>>вместе с напильником...
L>Что "вместе с напильником"?
те проблемы, о которых писал, если говорим о процедурах
L>Задумываться об этом действительно не стоит, т.к. эту проблему вполне себе решает Linq2Sql-овский дизайнер.
да, наверно у вас не было такой практики, когда полностью приходится убивать всю схему и генерировать снова , только для того, чтобы учесть все изменения, внесенные в базу после того, как схема уже была сгенерирована ... особенно приятно, когда есть вычисляемые поля/свойства, реализованный в partial classes
L>Я в свою очередь спрошу как вы собрались делать трекинг полей через аспекты, если я захочу работать с ними через reflection
ну мы так далеко зайдем вплоть до msil injection
Здравствуйте, DuШes, Вы писали:
DШ>вообщем, linq to sql (именно to sql) насктолько хорош, насколько его благополучно похоронили
Его похоронили не из-за того, что наколенные решения лучше, а из-за того, что есть EF, который во многом дублирует функциональность LINQ2SQL-а.
Кстати, ты вроде как пообещал озвучить претенции после того, как я приведу преимущества стандартного маппера. Ваш ход.
DШ>>>вместе с напильником...
L>>Что "вместе с напильником"? DШ>те проблемы, о которых писал, если говорим о процедурах
Напиши, пожалуйста полное предложение. Не получается у меня из "вместе с напильником" и "те проблемы, о которых писал, если говорим о процедурах" составить что-то осмысленное.
L>>Задумываться об этом действительно не стоит, т.к. эту проблему вполне себе решает Linq2Sql-овский дизайнер.
DШ>да, наверно у вас не было такой практики, когда полностью приходится убивать всю схему и генерировать снова , только для того, чтобы учесть все изменения, внесенные в базу после того, как схема уже была сгенерирована ... особенно приятно, когда есть вычисляемые поля/свойства, реализованный в partial classes
Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
L>>Я в свою очередь спрошу как вы собрались делать трекинг полей через аспекты, если я захочу работать с ними через reflection DШ>ну мы так далеко зайдем вплоть до msil injection
Здравствуйте, Lloyd, Вы писали: L>Кстати, ты вроде как пообещал озвучить претенции после того, как я приведу преимущества стандартного маппера. Ваш ход. L>>>Что "вместе с напильником"? DШ>>те проблемы, о которых писал, если говорим о процедурах L>Напиши, пожалуйста полное предложение. Не получается у меня из "вместе с напильником" и "те проблемы, о которых писал, если говорим о процедурах" составить что-то осмысленное.
как-раз и пытался доказать, что преимуществ кроме как визуального представления схемы и картинок нет...и в ваших доводах не увидел.
и раз уж речь зашла именно иб использовании процедур в рамках linq, то давайте говорить о процедурах — вот тут проблема а не в стандартном маппере на таблицы (мух отделите пожалуйста)..когда говорим о процедурах (а лично для себя не вижу пока ситуации, чтобы не использовать процедуры) вот тут и возникают проблемы с маппингом в неизвестность и проблемы синхронизации возвращаемых данных с классама-врапперами на стороне шарпа...странно, что вы их в упор не видите...хотя бы то, что стандартный враппер более-менее сложную процедуру прсото не поймет и не сгенерирует на основании данных, возвращаемых процедурой, вменяемый класс, который можно было бы потом применять в рамках c#.
насчет претензий — слова "претензия" означает несколько иное, я линк не ругал к вашему сведению, есть у него область приминения, а именно, настольные приложения или небольшие низконагруженные сайты..
ладно, пусть это будет претензия
1. не умеет работать с распределенными базами, где имеет место быть несколько баз и несколько серверов — или же вы используете несколько контекстов? тогда может быть и несколько соединений?
2. нельзя создать класс-сущность, маппируемую в разные таблицы...
3. нельзя без напильника научить методы возвращать наборы объектовбез написания вручную классов-врапперов няд этими данными
L>Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
вот и поделитесь — пока на ум только одно приходит, где-то кричится о том, что добавили новое поле в таблицу, и вручную делаем сотвествующее свойство в классе с указанием, откуда оно смаппировано — это если не убивая часть схемы
поверьте, все изменения у нас скриптуются и база версионная, для этого пиво не нужно, а под пивом можно много чего натворить
L>>>Я в свою очередь спрошу как вы собрались делать трекинг полей через аспекты, если я захочу работать с ними через reflection DШ>>ну мы так далеко зайдем вплоть до msil injection
L>не поможет, уверяю тебя.
это вот про что сейчас? ...можно конечно скатиться в сторону обсуждения плюсов и минусов использования аспектов, тогда да, наверно — не поможет вам
Здравствуйте, Spender, Вы писали:
S>Я тут ещё одно уточнение хочу вставить. S>Проблема именно в том, что SQL сервер перестает отвечать клиентам. Т.е. считается, что он очень сильно нагружается из-за того, что ему каждый раз приходится компилить запросы. Не знаю, очивидно ли это было из предыдуших моих постов или нет. Но так, на всякий случай.
Такое уж точно не из-за компиляции запросов.
Загрузку как мониторите? Когда и кому перестает отвечать? Может быть дело в блокировках? Может быть опять же в каком-то одном запросе и проблему решит один индекс? Какой запрос тормозит и жрет ресурсы?
Открывайте activity monitor, sql server profiler. Добавляйте логгирование. Попытайтесь изолировать проблему: посмотрите при каких действиях подвисает, а при каких — нет, от чего это зависит. Напишите нагрузочные тесты, воспроизводящие проблему. Понизьте уровень изоляции транзакций и посмотрите помогает или нет. Посмотрите планы самых ресурсоёмких запросов.
Короче нужно всего-то найти один bottleneck и устранить. Мой совет: найдите его сами, исправьте, и покажите начальнику. Если он кретин только в техническом плане, может он будет после этого считаться с вашим мнением, вместо того, чтобы принимать кретинские технические решения.
Здравствуйте, DuШes, Вы писали:
L>>Напиши, пожалуйста полное предложение. Не получается у меня из "вместе с напильником" и "те проблемы, о которых писал, если говорим о процедурах" составить что-то осмысленное.
DШ>как-раз и пытался доказать, что преимуществ кроме как визуального представления схемы и картинок нет...и в ваших доводах не увидел.
в моих доводах ни слова не было про это.
DШ>и раз уж речь зашла именно иб использовании процедур в рамках linq, то давайте говорить о процедурах — вот тут проблема а не в стандартном маппере на таблицы (мух отделите пожалуйста)..
Маппер на таблицы и маппер на резалтсет процедуры — это один и тот же маппер.
DШ>когда говорим о процедурах (а лично для себя не вижу пока ситуации, чтобы не использовать процедуры) вот тут и возникают проблемы с маппингом в неизвестность и проблемы синхронизации возвращаемых данных с классама-врапперами на стороне шарпа...странно, что вы их в упор не видите...хотя бы то, что стандартный враппер более-менее сложную процедуру прсото не поймет и не сгенерирует на основании данных, возвращаемых процедурой, вменяемый класс, который можно было бы потом применять в рамках c#.
Маппер на занимается генерацией этого класса. Его задача — результат выполнения процедуры залить в тот класс, в который ему скажут.
DШ>насчет претензий — слова "претензия" означает несколько иное, я линк не ругал к вашему сведению, есть у него область приминения, а именно, настольные приложения или небольшие низконагруженные сайты.. DШ>ладно, пусть это будет претензия DШ>1. не умеет работать с распределенными базами, где имеет место быть несколько баз и несколько серверов — или же вы используете несколько контекстов? тогда может быть и несколько соединений?
При чем тут маппер?
DШ>2. нельзя создать класс-сущность, маппируемую в разные таблицы...
Я так понимаю ты работаешь с процедурами. Так вот в этом случае ты вполне можешь указать, одну и ту же сущность как результат работы разных процедур. Единственно, ты не сможешь воспользоваться ею для update-а в базу.
DШ>3. нельзя без напильника научить методы возвращать наборы объектов без написания вручную классов-врапперов няд этими данными
Чего-чего? Еще раз и помедленнее.
Какие методы? Почему нельзя? При чем тут маппер?
L>>Конечно, у меня не возникало таких проблем. У нас на проекте есть сложившаяся процедура внесения изменений в схему базы, благодаря которой нет необходимости "убивать всю схему и генерировать снова". Это экономит кучу времени. Рекомендую вам с коллегами сесть как-нить вечерком с пивком и решить раз и навсегда, как по-правильному вносить изменения.
DШ>вот и поделитесь — пока на ум только одно приходит, где-то кричится о том, что добавили новое поле в таблицу, и вручную делаем сотвествующее свойство в классе с указанием, откуда оно смаппировано — это если не убивая часть схемы
Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
L>>>>Я в свою очередь спрошу как вы собрались делать трекинг полей через аспекты, если я захочу работать с ними через reflection DШ>>>ну мы так далеко зайдем вплоть до msil injection
L>>не поможет, уверяю тебя.
DШ>это вот про что сейчас? ...можно конечно скатиться в сторону обсуждения плюсов и минусов использования аспектов, тогда да, наверно — не поможет вам
А вы не личности не переходите. У нас проблем с Linq2Sql-м как-то не наблюдается.
Кстати, ты так и не сказал, чем AOP будет лучше по сравнению с банальным генерированием сущностей из dbml-я.
Здравствуйте, Jakobz, Вы писали:
J>Такое уж точно не из-за компиляции запросов. J>Загрузку как мониторите? Когда и кому перестает отвечать? Может быть дело в блокировках? Может быть опять же в каком-то одном запросе и проблему решит один индекс? Какой запрос тормозит и жрет ресурсы? J>Открывайте activity monitor, sql server profiler. Добавляйте логгирование. Попытайтесь изолировать проблему: посмотрите при каких действиях подвисает, а при каких — нет, от чего это зависит. Напишите нагрузочные тесты, воспроизводящие проблему. Понизьте уровень изоляции транзакций и посмотрите помогает или нет. Посмотрите планы самых ресурсоёмких запросов. J>Короче нужно всего-то найти один bottleneck и устранить. Мой совет: найдите его сами, исправьте, и покажите начальнику. Если он кретин только в техническом плане, может он будет после этого считаться с вашим мнением, вместо того, чтобы принимать кретинские технические решения.
Если бы я все это умел У нас есть человек специальный для этого. Он полностью занимается БД на стороне SQL сервера. Может даже оптимизирует что-то там. Но вряд ли.
Спасибо за совет. Попробую все это рассказать шефу.
Здравствуйте, Lloyd, Вы писали: L>>>не поможет, уверяю тебя.
[skipped]
я думаю, весь разговор скатился к придираниям к словам; под linq to sql и понимайте маппер в/из базы данных, щас еще начнем обсуждать linq провайдеры ...
я вопринимаю linq to sql как некий FW, который диктует правила и накладывает ограничения для работы с данными, если возникает необходимость использования напильника как например для работы с процедурами и танцев с бубнами, то в топку..
L>А вы не личности не переходите. У нас проблем с Linq2Sql-м как-то не наблюдается. L>Кстати, ты так и не сказал, чем AOP будет лучше по сравнению с банальным генерированием сущностей из dbml-я.
по-моему, продолжать бесполезно я на личности не переходил, может вы
в рамках этой темы мы не будем обсуждать преимущества и минусы аспектов, если это вас так интересует, создайте новую тему или добро пожаловать в поиск...и мысль об аоп была рождена с учетом мысли ручного кодирования классов-врапперов
еще раз: если вы используете linq to sql, то слава богу и продолжайте его использовать, из все нашей дискуссии я остался убежден в том, что когда речь заходит об использовании процедур в линке, то тут его смысл теряется...из ваших слов все преимущества сводятся только:
1. Он есть
2. качественно оттестирован толпой тестеров в микрософте
3. по нему есть документация
4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
минусы я показал, жалко что не видите или не хотите видеть, зато:
Я так понимаю ты работаешь с процедурами. Так вот в этом случае ты вполне можешь указать, одну и ту же сущность как результат работы разных процедур. Единственно, ты не сможешь воспользоваться ею для update-а в базу.
Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
да, преимущества налицо , а теперь представим, что полностью перешли на использование процедур, так себе и представляю, как вы вручную пишите классы обертки над возвращаемыми данными...потому что ну не может и не умеет и не сможет linq to sql designer сгенерировать на основе t-sql кода то представление класса, которое требуется...за исключением редких банальных select * from;
предлагаю закрыть, судя по всему каждый останется при своем мнении
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, kenzo_u, Вы писали:
_>>А может лучше все запросы держать в одном месте? Либо только в виде ХП, либо только в коде программы в DAL-слое? IB>Если есть DAL, то где конкретно находятся запросы для квалифицированного разработчика — фиолетово. Для стажеров — жестко, только хранимки.
Почему фиолетово для квалифицированного разработчика и почему только хранимки для стажеров?
Здравствуйте, DuШes, Вы писали:
DШ>я думаю, весь разговор скатился к придираниям к словам; под linq to sql и понимайте маппер в/из базы данных,
не надо менять предмет обсуждения. вы высказались про linq2sql-овский маппер, что он "ужос":
L>+ маппиниг резалтсета хранимой процедуры на объекты.
вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
Что вы тут имели в виду конкретно маппер или все-таки весь linq2sql целиком?
DШ>щас еще начнем обсуждать linq провайдеры ...
зачем? разговор ведь идет не о linq-е, и даже не о linq2sql-е, а о его маппере. зачем в этом котексте обсуждать какие-то провайдеры?
DШ>я вопринимаю linq to sql как некий FW, который диктует правила и накладывает ограничения для работы с данными, если возникает необходимость использования напильника как например для работы с процедурами и танцев с бубнами, то в топку..
Почему вы отказываетесь продемонсnрировать, какие у вас возникли проблемы с маппером?
DШ>в рамках этой темы мы не будем обсуждать преимущества и минусы аспектов, если это вас так интересует, создайте новую тему или добро пожаловать в поиск...и мысль об аоп была рождена с учетом мысли ручного кодирования классов-врапперов
Нет, меня интересует не OAP как таковое, а преимущества использования AOP перед использванием классов сущностей, создаваемых .dbml-ем.
DШ>еще раз: если вы используете linq to sql, то слава богу и продолжайте его использовать, из все нашей дискуссии я остался убежден в том, что когда речь заходит об использовании процедур в линке, то тут его смысл теряется...из ваших слов все преимущества сводятся только: DШ>
DШ> 1. Он есть
DШ> 2. качественно оттестирован толпой тестеров в микрософте
DШ> 3. по нему есть документация
DШ> 4. если с ним возникнет какая-то проблема, существует большое кол-во людей, которые его использовали в очень разных сценариях и они смогут мне помочь
еще раз повторюсь. выше по ветке я предполагал, что речь идет исключительно о маппере. давайте его и обсуждать, а не весь linq2sql целиком.
DШ>минусы я показал, жалко что не видите или не хотите видеть, зато: DШ>
DШ>Я так понимаю ты работаешь с процедурами. Так вот в этом случае ты вполне можешь указать, одну и ту же сущность как результат работы разных процедур. Единственно, ты не сможешь воспользоваться ею для update-а в базу.
DШ>
DШ>Никто никуда не кричит. Тот, кто изменяет схему, обязан изменить и соответствующие entity. Самый простой способ — это внести это изменение вручную в dbml.
DШ>да, преимущества налицо , а теперь представим, что полностью перешли на использование процедур, так себе и представляю, как вы вручную пишите классы обертки над возвращаемыми данными...потому что ну не может и не умеет и не сможет linq to sql designer сгенерировать на основе t-sql кода то представление класса, которое требуется...за исключением редких банальных select * from;
Еще раз напоминаю, что предмет обсуждения маппер, а не linq2sql designer.
DШ>предлагаю закрыть, судя по всему каждый останется при своем мнении
Предлагаю продолжить. Просто давай сузим тему до маппера исключительно и не будем с нее сходить. Ок?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, DuШes, Вы писали:
DШ>>я думаю, весь разговор скатился к придираниям к словам; под linq to sql и понимайте маппер в/из базы данных,
ну давайте продолжим L>Почему вы отказываетесь продемонсnрировать, какие у вас возникли проблемы с маппером?
я не говорил о проблемах с маппером, я вам уже объяснил, что маппер и дизайнер рассматриваю вместе, возможно поставил вас в заблуждение,и вот собственно невозможность его использования применительно к процедурам для построения схемы является той проблемой, которую пытался обозначить
L>не надо менять предмет обсуждения. вы высказались про linq2sql-овский маппер, что он "ужос": L>
L>+ маппиниг резалтсета хранимой процедуры на объекты.
L>вот это и есть ужос, который превратится в будущем в еще более ужос, когда придется расширять классы или структуру таблиц...
L>Что вы тут имели в виду конкретно маппер или все-таки весь linq2sql целиком?
не знаю как вы, но лично я не отделяю маппер и linq to sql data context designer и рассматриваю их как неделимое целое ... дык вот, маппер для процедур — его нет да в принципе теоретически быть не может, когда речь будет идти о возвращаемом датасете из нескольких таблиц...
в целом, если вы просто говорите что мол да, маппер свои задачи чисто по маппингу в/из базы/классы выполняет — то да, тут не соглашаться не с чем...это самое простое что есть забиндить поле из таблицы в соотвествующее свойство из класса,
но использовать чисто маппер из всего linq to sql ради только маппера вообще теряет смысл — и на этом давайте закончим наше обсуждение именно маппера, а не в целом linq to sql
теперь в целом по linq to sql в рамках стартовой темы и применительно использования процедур: мое мнение — смысла использовать сам linqtosql и в том числе и сам его маппер смысла не имеет, если схема строится только на процедурах, более того, в более-менее сложной системе, одно из требований которой скорость обработки данных, использовать linqtosql даже без использования процедур тоже не имеет смысла
)
Мы уже победили, просто это еще не так заметно...
... особенно приятно, когда есть вычисляемые поля/свойства, реализованный в partial classes
тогда может быть и несколько соединений?
У нас есть человек специальный для этого. Он полностью занимается БД на стороне SQL сервера. Может даже оптимизирует что-то там. Но вряд ли.
