Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 19   вперед  Ctrl
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы
Так язык - это желаемое или необходимое?

Срорее, необходимое.
зы
Почему не может быть ORM только для конкретной базы?

Отчего ж не может, может. L2S - для конкретного типа сервера (MSSQL), например.
зы
Да пусть работает, я про заявление о строгой типизации базы

Ты ж спросил про "конкретность базы", а теперь говоришь о другом - о типизации. Определись. Типизация априори должна быть в ORM, исходя даже из самого названия - объектный маппинг.
8 янв 12, 15:39    [11870249]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
ViPRos
Member

Откуда:
Сообщений: 9885
кусок соственной проги со всеми приблудами кто нить покажет?
или вы все работаете в цру?
8 янв 12, 15:46    [11870260]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
ViPRos
Member

Откуда:
Сообщений: 9885
самый симпотный орм - kynetic
8 янв 12, 15:47    [11870263]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
ViPRos
Member

Откуда:
Сообщений: 9885
ауууу
скукота :(
8 янв 12, 16:01    [11870293]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
МСУ
зы
Так язык - это желаемое или необходимое?

Срорее, необходимое.
зы
Почему не может быть ORM только для конкретной базы?

Отчего ж не может, может. L2S - для конкретного типа сервера (MSSQL), например.

ок, тогда mybatis/ibatis, получается, тоже не ORM? Там нет собственного языка, транслируемого в XXX. Ну и наверное ещё каких-то свистелок, которые ты называешь необходимыми. Просто ты явно не ответил.

МСУ
зы
Да пусть работает, я про заявление о строгой типизации базы

Ты ж спросил про "конкретность базы", а теперь говоришь о другом - о типизации. Определись.

да что ты, я не спрашивал про "конкретность базы". Я вообще адресовал свой вопрос Lelouch, к тебе у меня были другие. Не люблю смешивать.
8 янв 12, 16:43    [11870371]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы
ок, тогда mybatis/ibatis, получается, тоже не ORM? Там нет собственного языка, транслируемого в XXX. Ну и наверное ещё каких-то свистелок, которые ты называешь необходимыми. Просто ты явно не ответил.

Согласен, что "неявно" ответил. И не отвечу, потому что нет однозначного определения ORM. Каждый продукт сам себя позиционирует.
Хибер позиционирует себя как ORM.
Telerik OpenAccess позиционирует себя как ORM.
BLToolkit позиционирует себя как ORM.
EF позиционирует себя как ORM.
...
Enterprise Library Data Access Block позиционирует себя как практику (хелпер, другими словами).

зы
да что ты, я не спрашивал про "конкретность базы". Я вообще адресовал свой вопрос Lelouch, к тебе у меня были другие. Не люблю смешивать.

Ок, тогда сорри.
8 янв 12, 16:53    [11870384]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы, по поводу JdbcTemplate: Доступ к данным в Spring

...
Существует много статей о том, как делать инъекцию зависимости в Spring, но очень мало толковой информации о подключениях к базам данных. В Spring это можно делать либо напрямую при помощи JDBC либо использовать ORM технологии, например, Hibernate.


Согласись, очевиден четкий контраст: либо горбатый, либо не горбатый.
8 янв 12, 16:58    [11870387]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1880
зы
Lelouch
Зачем мне динамическая типизация если база строго типизирована?

Немного вброшу - а если база NoSQL? А то тут все в порыве спора немного на скуль сервере зациклились :)


Раз уж именно мне, то :

1) Тема топика SQL vs ORM. )))
2) Честно, не сталкивался с нетипизированными хранилищами
3) noSQL бывает типизированным (это ответили до меня)
4) Даже при отсутсвтии строгой типизации в бд использую ORM и получу строгую типизацию.

Подход без строгой типизации (нетипизированный датасет) все равно особых плюсов не имеет - при работе или придется приводить типы, или использовать dynamic, что сильно мешает и может привести к краху в рантайме при попытке использования несуществующего метода / поля / свойства, etc.
Или я не правильно понял вопрос?
8 янв 12, 17:11    [11870410]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1880
P.S. Из примеров по MongoDB, приводимых Вами:
BsonDocument book;
string author = book["author"].AsString;
DateTime publicationDate = book["publicationDate"].AsDateTime;
int pages = book["pages", -1].AsInt32; // default value is -1

Как видите, все равно преобразования типа необходимо.
8 янв 12, 17:21    [11870434]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1880
*
приводимой
8 янв 12, 17:22    [11870437]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Парамон
Member

Откуда:
Сообщений: 1468
ViPRos
кусок соственной проги со всеми приблудами кто нить покажет?
или вы все работаете в цру?


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

К сообщению приложен файл. Размер - 26Kb
8 янв 12, 17:31    [11870451]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
Lelouch
P.S. Из примеров по MongoDB, приводимых Вами:

Как видите, все равно преобразования типа необходимо.

преобразование необходимо исключительно для работы с данными в строго типизированном языке C#. Если клиентом будет javascript, то преобразование уже не нужно ;) Да и если в одной строке может лежать документ с полем "foo" и значением типа string, а в другой - документ с полем "foo" и значением типа number, то это и называется отсутствие строгой типизации в базе.
8 янв 12, 17:53    [11870489]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
МСУ,

я все к тому спрашивал, чтобы вляпаться с тобой в очередную игру слов про ORM или не ORM. Если называть инструмент ORM'ом, если у него есть базовый функционал маппинга сырых данных из базы на какую-то модель данных, то да, без ORM сейчас почти никто не обходится и для игнорирования нужны веские причины. Хотя вот в небольшом проекте с NoSQL (для Lelouch заодно) вместо ORM был простой валидатор по динамической схеме данных. Потому что были динамические формы и никакой объектной модели (кроме списка пользователей), и нужно было всего-лишь сохранить форму как документ, и уметь смапить документ обратно на форму для редактирования.

Если настаивать на понятии ORM как на обязательном присутствии свистелок и переделок, то примеров, почему не нужно использовать такой тяжелый инструмент как ORM, уже может быть много. Либо нужен баланс. Для простых модулей типа user management нет смысла изобретать очередной CRUD велосипед, а уже там, где преимущественно нужны быстрые, разнообразные и эффективные выборки с отображением данных, ORM избыточен. Особенно хибернейт.
8 янв 12, 17:54    [11870491]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
"чтобы НЕ вляпаться" конечно же
8 янв 12, 17:55    [11870494]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
Парамон
Вот вам, маленький запросик которых в приложении сотни.
Конечно вы его протестировали в студии, посмотрели план, и так каждый раз после любого изменения.
Эффективно.. :)

почему любители compile-time проверок все время любят приводить в пример опечатки в строках? А если я опечатался и написал >= , или вместо нуля единицу? А сколько в адовом 11867369 запросе можно опечаток наделать — я вообще молчу. У тебя же все равно будут юниттесты, правильно? :) они и свалятся в случае ошибки.
8 янв 12, 18:09    [11870529]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы
МСУ, я все к тому спрашивал, чтобы не вляпаться с тобой в очередную игру слов про ORM или не ORM.

Я это почувствовал изначально, поэтому старался "неявно" отвечать. Но когда вопрос стал ребром "горбатый или не горбатый" - я отписался про "самопроизвольную" трактовку вендора.

Но, так или иначе, мы привыкли к тому, что в ORM'ах есть
1. Готовые для работы классы (либо пишем руками, либо кодогенерируем с хранилища)
2. Язык общения с хранилищем (транслятор в SQL)
3. По возможности поддержка различных видов БД (нетрудно реализовать из п.2)
4. По возможности поддержка возможности создания новой БД из набора классов (в хибере делается одной строчкой SchemaExport.Execute())

зы
Если называть инструмент ORM'ом, если у него есть базовый функционал маппинга сырых данных из базы на какую-то модель данных

Маппинг - это самое последнее и самое простое. Нужна схема, прежде всего. Нужны классы. Нужен движок-транслятор. Вот, что самое сложное.

[quot зы]такой тяжелый инструмент как ORM
В том-то и соль, что он не тяжелый. Он шустр и понятен, как березовый лист. Запросы выполняются там же на сервере, программист же общается с типизированными данными. Скорость та же. Микросекунды на маппинг объектов в коллекции не в счет. Тот же датасет дольше будет заполняться, чем наполнится коллекция того же хибера или EF.
Самое шустрое же - это IDataReader, но работать с ним так или иначе невозможно.
8 янв 12, 18:09    [11870530]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы
почему любители compile-time проверок все время любят приводить в пример опечатки в строках? А если я опечатался и написал >= , или вместо нуля единицу?

Потому, что данный вид ошибки является самым распространенным. А от логической ошибки же (ошибки в бизнес-логике) ничего не спасёт, даже серебряная пуля.
зы
У тебя же все равно будут юниттесты, правильно? :) они и свалятся в случае ошибки.

Точно так же, можно ошибиться в юнит-тесте и написать 0 вместо 1. Так что мы ходим рекурсивно по кругу.
8 янв 12, 18:12    [11870540]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
зы
Member

Откуда:
Сообщений: 2530
МСУ

Точно так же, можно ошибиться в юнит-тесте и написать 0 вместо 1. Так что мы ходим рекурсивно по кругу.

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

МСУ
Маппинг - это самое последнее и самое простое. Нужна схема, прежде всего. Нужны классы. Нужен движок-транслятор. Вот, что самое сложное.

маппинг - это результат работы всего, что ты написал выше. Именно что последнее, и базовое :) Транслятор->база->схема->маппинг. Тут именно что ничего тяжелого. Тяжелое и непредсказуемое начинается когда подключают, например, хибернейт. Если он избыточен для задачи, то достаточно jdbctemplate/mybatis для получения результата в виде POJO, с которым уже можно работать дальше используя парадигмы объектов. В основном это некая небольшая простая постобработка на стороне приложения перед выводом на клиент.
Тут нет серебряной пули, так что спор — нужен ORM или нет без конкретной задачи сводится к простому мерянью пиписьками вида "а у меня проект больше и без ORM мы бы его делали в 10 раз дольше".
8 янв 12, 18:25    [11870604]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
зы
но все-таки давай рассматривать юнит-тесты как достаточный уровень защиты от подобных ошибок.

Ок. Но зачем доводить до последнего рубежа обороны, если можно на начальном этапе отсеять такую ошибку (ошибки именований или типов).
Далее - продуктивность и удобство работы (интелиссенс). Влияет ли на скорость и качество разработки? Или в помойное ведро его, этот подсказыватель? Думаю, тут всё очевидно.

зы
маппинг - это результат работы всего, что ты написал выше. Именно что последнее, и базовое :)

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

[quot зы]Тяжелое и непредсказуемое начинается когда подключают, например, хибернейт. Если он избыточен для задачи, то достаточно jdbctemplate/mybatis для получения результата в виде POJO, с которым уже можно работать дальше используя парадигмы объектов.[/quot
Не понимаю, всё же. В чём тяжелость и избыточность хибера? Нужно переключиться на другую БД (например, Oracle) - переключаем провайдер в конфиге. Нужно развернуть базу по схеме в инсталляторе - вызываем метод, который по схеме все сделает.

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

зы
Тут нет серебряной пули, так что спор — нужен ORM или нет без конкретной задачи сводится к простому мерянью пиписьками вида "а у меня проект больше и без ORM мы бы его делали в 10 раз дольше".

Нужен. Тысячу раз нужен, зы. Однозначно нужен, даже если база постоянна и прочие фантики не интересны.
8 янв 12, 18:39    [11870652]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Enomay
Member

Откуда:
Сообщений: 145
Lelouch
P.S. Из примеров по MongoDB, приводимых Вами:
BsonDocument book;
string author = book["author"].AsString;
DateTime publicationDate = book["publicationDate"].AsDateTime;
int pages = book["pages", -1].AsInt32; // default value is -1

Как видите, все равно преобразования типа необходимо.


ну конечно. вы бы еще работу с чистым rest показали.
использовать готовую библиотеку для доступа к MongoDB с поддержкой типов слабо?
хотя бы вот так http://habrahabr.ru/blogs/aspnet_mvc/93598/
8 янв 12, 18:58    [11870709]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Парамон
Member

Откуда:
Сообщений: 1468
К МСУ добавить нечего, разве что - носить стринги не наша ориентация )
8 янв 12, 19:03    [11870730]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Enomay
Member

Откуда:
Сообщений: 145
зы
Для простых модулей типа user management нет смысла изобретать очередной CRUD велосипед, а уже там, где преимущественно нужны быстрые, разнообразные и эффективные выборки с отображением данных, ORM избыточен. Особенно хибернейт.


ORM не исключает быстрых и эффективных выборок.
его основная задача - маппинг. с этой задачей он отлично справляется. это на порядок удобнее нежели работать с классическим ADO.NET. он снимает кучу рутинной работы.

но и логику на нем строить так же можно, и нужно, если есть необходимость.
для примера. была необходимость отображать все записи из определенных таблиц.
через время появилось требование записи не удалять физически, а маркировать как Deleted. используя ORM, я пропишу это условие в одном месте и все запросы будут работать правильно. в вашем случае вы будете тупым поиском пересматривать все текстовые запросы и хранимые процедуры. а если добавится еще условие? будете лазить еще и еще. при этом нет никакого контроля, что вы не сломали нигде ничего. ведь тестами это покрыть вы не можете.

используя ORM, я могу наследовать логику, а значит и запросы к базе. в вашем случае, вам придется использовать динамический SQL, который привнесет дополнительный ад в проект.

использовать чистый сиквел имеет смысл только тогда, когда нужно обрабатывать огромные объемы данных. обычно это OLAP.
8 янв 12, 19:06    [11870744]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Lelouch
Member

Откуда: Москва
Сообщений: 1880
Enomay
Lelouch
P.S. Из примеров по MongoDB, приводимых Вами:
BsonDocument book;
string author = book["author"].AsString;
DateTime publicationDate = book["publicationDate"].AsDateTime;
int pages = book["pages", -1].AsInt32; // default value is -1

Как видите, все равно преобразования типа необходимо.


ну конечно. вы бы еще работу с чистым rest показали.
использовать готовую библиотеку для доступа к MongoDB с поддержкой типов слабо?
хотя бы вот так http://habrahabr.ru/blogs/aspnet_mvc/93598/


А к чему ваш комментарий, можно вопрос? Может сначала перечитаете вопрос, на который я отвечал?
8 янв 12, 19:07    [11870746]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Enomay
Member

Откуда:
Сообщений: 145
МСУ
Но так или иначе, самое ценное в ORM - это типизация хранилища, как следствие родной человеческий интелиссенс, с которым одно удовольствие работать. Рутинные же SELECT FROM WHERE в прошлом.


на самом деле самое ценное в ORM - это возможность работать с объектами, а не строками в таблицах. это существенно при использовании ООП.
8 янв 12, 19:10    [11870764]     Ответить | Цитировать Сообщить модератору
 Re: ORM vs sql  [new]
Enomay
Member

Откуда:
Сообщений: 145
Lelouch
А к чему ваш комментарий, можно вопрос? Может сначала перечитаете вопрос, на который я отвечал?


вы написали что необходимо преобразование. преобразование чего во что?
конечно в том или ином виде оно всегда и везде есть. я уверен что даже внутри сиквела. но используя нормальные ORM, у вас не возникает необходимость делать это самому. и к тому же отпадает необходимость в том коде, что вы привели как пример.
8 янв 12, 19:11    [11870767]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 19   вперед  Ctrl
Все форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM Ответить