Не Linq к SQL упускают суть? Разве ORM-картопостроители не являются (SubSonic, и т.д.) субоптимальными решениями?

Ted Neward записал замечательное эссе по своему взятию на этом предмете - что ORM's является "Вьетнам" информатики...

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

thereВґs без проблем с linq, но с теми, кто использует его и игнорирует то, что происходит "негласно"

я все еще, предпочитают пачкать руки с SQL. По крайней мере, iВґll знают exatcly, что происходит.

Я должен согласиться, что вспышка инструментов ORM в основном происходит от раздражения из-за записи SQL, контакта с любым драйвером DB, который необходимо использовать, внутренне абстрагируя между DBS (Oracle по сравнению с SQL Server, по сравнению со что для возможности многократного использования кода), и преобразовывая типы данных.

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

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

Для.NET, в частности, что я очень видел бы вместо Linq, созданный способом отобразить определение класса на базовый источник данных к базовому хранилищу данных, и иметь всю инфраструктуру просто работают.

, Другими словами, я мог просто сказать "Сотрудника. Имя = 'rally25rs'"; и свойство объекта изменилось бы, и под которым оно сохранится к самому хранилищу данных. Просто SQL канавы полностью вместо того, чтобы пойти 1/2 путем как Linq к SQL делает теперь.

, Конечно, решение как этот поднимает проблемы с производительностью, обработкой транзакции, и т.д.

, Возможно, все понятие языка программирования и реляционной базы данных должно заново продуматься и перестроено? В их ядре они - абсолютно отдельные и разделенные объекты. Возможно, его время только к угробило "реляционную sql осведомленную базу данных" и создает следующую вещь, подхлестывает выполнение строки кода, непосредственно воздействовал бы на базу данных.

Мне не нравится ни одно из текущих решений - но я предпочитаю больше вариантов по меньшему количеству вариантов;-)

я использовал OODBMS в проекте давно, который был самым близким к разбиранию в нем (к сожалению, продукт имел некоторые отвратительные ошибки и ужасную техническую поддержку) - объектная персистентность была в основном невидима , обработанный негласно (через генератор кода препроцессора) и управляла очень простым Обновлением, Удалите и Найдите методы и простые контейнеры.

я хотел бы видеть это (и возможно некоторая модель объектного объекта хорошо уже делает это), снова, с OCL (Объектный Ограничительный Язык) как собственный мультиязык объектных запросов

Codemonkey делает очень правильное замечание: хранимые процедуры предлагают уровень абстракции, которая выполняет часть обещания более сложных моделей ORM. Это не интуитивно на первый взгляд, но я могу думать о примере прямо от моего собственного кода. У меня есть "регистрация" sproc, который касается почти дюжины таблиц (кому принадлежит этот идентификатор? у них есть членство? Есть ли какие-либо сообщения? Они зарабатывают очки за эту регистрацию? и т.д.).

Моделирование этого в C# - неважно, насколько сложный модель данных - никогда не была бы хорошей идеей, поскольку это требует многих прохождений "по проводу", чтобы проверить данные и обновить различные таблицы. В то время как это верно, что можно обработать sprocs в Linq или другом ORMS, все, в чем я нуждаюсь , класс обертки, который позволяет мне называть sproc со стандартными параметрами C#. На самом деле это было такой срочной необходимостью для меня, что я записал генератор кода в T-SQL для создания таких оберток.

Я думаю действительное решение, в котором они нуждались, было что-то больше как литерал SQL. Поддержки VB.Net 9.0 литералы XML , которые позволяют Вам писать право XML в своем коде и удостоверяться, что это проверено и встречает DTD. Столь же хорошей функцией были бы литералы SQL, которые позволяют Вам писать встроенный код SQL в своем коде.Net и проверять ее IDE. Должна была бы быть своего рода сменная архитектура к проверке информации против базы данных, но это могло быть просто написано для популярных механизмов базы данных. Это обеспечило бы то, что я думаю, чтобы быть действительным решением к проблеме, которую они пытались решить, не обращаясь к субоптимальным решениям.

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

Я делаю и приложение базы данных и программирование распределенного приложения (сеть и скомпилированный) и испытываю желание не торопиться для разработки основанных на хранимой процедуре уровней доступа к данным, время хорошо потраченный. Лично, я предпочитаю делать моделирование данных и определять, что необходимый procs рано в процессе разработки..., кажется, помогает раскрыть проблемы логики/структуры дизайна/интерфейса.

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

Однако я заинтригован понятием OODBMS и надеждой, что когда-нибудь я возьмусь за работу над некоторыми в продуктивной среде.

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

, Если Вы позволяете Объектной модели и ORM, диктуют Вашу модель данных, Вы только закончите с плохой моделью данных, которая не нормализована и/или содержит артефакты от объектной модели.

1 таблица = 1 класс является плохой идеей.

Для запуска с Вас никогда имейте классы, которые представляют many-many или таблицы ссылки many-one. Они соответствуют дочерним наборам в объектной модели - сами ссылки не являются объектами.

при обработке базы данных как таблиц, чтобы просто содержать объекты в строках (один общий подход) и предоставить прямой доступ приложения к таблицам, Вы бросаете все преимущества определения интерфейсного слоя сервисов базы данных, которые база данных может использовать для защиты ее периметра.

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

Оператор Dmitry, что Разработчику не нравится SQL, может иметь партию истины, но решением не является только ORM. Решение состоит в том, чтобы нанять в качестве части группы разработчиков Разработку DBA. В моей компании у моей группы разработчиков .NET есть превосходная Oracle DBA, кто не делает абсолютно никакого производства dba работа. Его роль в нашей команде является моделированием данных, физический дизайн дб, создавая сохранил procs, анализ данных и т.д. Он - причина, наша сторона дб является настолько чистой и работает. Весь наш доступ DB через сохраненный procs.

, Что такое разработка DBA? http://www.simple-talk.com/sql/database-administration/what-use-is-a-development-dba/

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

я скажу, что моя причина разработки ORM не была из-за "несоответствия импеданса" между SQL и императивным программированием, а скорее только в целях становления агностиком платформы базы данных. Бывшей проблемой необходимости записать больше кода для управления персистентностью является маленькое препятствие, это легко разрешено, если Вы только работаете с одним поставщиком базы данных. Становление агностиком платформы базы данных является намного более сложной проблемой, и imo оказывает намного большее влияние на доходность Вашего бизнеса, предполагающего, что как я Вы планируете продать программное обеспечение другим людям (и только используют его в доме).

, Когда я начал работать над своими инструментами ORM несколько лет назад, понятие было непрактично на моем предпочтительном языке, большинство людей, с которыми я говорил, не поняло, почему я работал над ним, и некоторая хорошо уважаемая речь в сообществе так же очень как написала статьи в торговых журналах, указывающих, что то, что я уже сделал, не было только невозможно, но также и нежелательно. Некоторые из тех же причин были приведены - это слишком сложно, это ограничивает, и это добавляет наверху. Сегодня у того же сообщества есть по крайней мере три популярных инструмента абстракции базы данных (хотя существуют некоторые дебаты об определении термина ORM). Причина, почему я упоминаю это, состоит в том, потому что, когда я начал работать над этими инструментами, исходные возражения несли намного больше веса, чем они делают теперь. Базовая технология оба аппаратных и программных обеспечения изменилась за прошедшие годы для создания этих инструментов намного более практичными в конечном счете. Моя тенденция состоит в том, чтобы попытаться взять Лонгвью программного обеспечения и работы над решениями, которые, возможно, не совсем практичны все же, но это станет практичным скоро. Таким образом, учитывая, что я не высчитал бы LINQ к Объектам как хорошее решение для определенных проблем.

я также склонен предпочитать больше опций, а не меньше. Таким образом, в то время как я могу поддерживать идею позади разработки LINQ к Объектам, я менее склонен поддерживать уничтожение LINQ к SQL merelyu, потому что LINQ к Объектам стал доступным. Объекты являются большими для того, чтобы сделать то, что делают объекты, нет никакого вопроса об этом... В моем (снова смещенный) мнение, проблема происходит в этом, люди видят любой данный инструмент или парадигму программного обеспечения как "чудодейственное средство" и хотят настоять, чтобы все было тем путем. Известно, что реляционная база данных очень хороша в обработке определенных других задач, сообщая о быть хорошим примером. Так, по-моему, это - вид стрельбы в себя в ноге, чтобы настоять, чтобы все было объектами, потому что тогда Вы вынуждаете себя использовать неэффективный инструмент для задания. Таким образом относительно создания отчетов, в частности, избавления от LINQ к SQL и использованию только LINQ к Объектам, по крайней мере, на поверхности звучит мне как инверсия абстракции анти-шаблон.

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

Историческая перспектива.

, Когда Codd и. al. первоначально разрабатывали теорию и реализацию реляционных баз данных, один совершенно отдельный вопрос был, "Как мы запрашиваем эти вещи"? Много стратегий и синтаксисов были предложены с различными достоинствами и недостатками. Один из тех кандидатов был SQL (в его самой ранней форме, очевидно.) Другой был QBE (Запрос Примером). Другого назвали "quel", я верю; и было несколько других. SQL, конечно, не стал доминирующим, потому что это приветствовалось как выше всех других. Unfornately, тем не менее, другие в значительной степени исчезли к бедности нас всех (потому что они могли использоваться одновременно на тех же данных.)

, Если Microsoft имеет хорошую историю, что они восстанавливают один из этих других языков, или изобрели достойное дополнение, тогда я думаю, что нам было бы целесообразно послушать. Но до сих пор все, что я видел, является еще одним "Одно Кольцо Для Управления Их Всех".

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

Как Dmitriy указал , разработчики не знают SQL. Более точно большинство знает SQL, но не делает , понимают это и определенно не любят, таким образом, они имеют тенденцию искать чудодейственное средство, создавая спрос на вещи как Linq для создания иллюзии (гм, абстракция), что они не используют ничего различного, чем их любимые классы.

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

Некоторыми решениями ORM является определенная польза (например, JPA/Hibernate), не потому что использование их Вы не должны волноваться о SQL. На самом деле для использования JPA эффективно Вам нужно очень глубоко понимание DB в целом, запрашивая способности в частности. Положительная сторона - то, что они заставляют машину сделать растачивание к точке, где это автоматически генерирует всю базу данных с нуля.

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

Я согласовываю 100%. Многое из этого является результатом того, что процедурные навыки кодирования и навыки кодирования SQL очень отличаются; и этот факт широко не подтверждается. Так, до той реализации хиты программисты ищут способы сделать их набор навыков передаваемым от одного домена до другого.

Это не работает.

просто необходимо учиться как фазовому сдвигу: изучите, как думать о Вашем коде по-другому, в зависимости от которого домена Вы обращаетесь.

кто-либо еще заметил, сколько еще сложный и подробный запрос становится, когда он отображается от SQL до LINQ? Как, во всех примерах онлайн?

Дизайн Linq и linq к платформе объектов, конечно, имеют использование в качестве orm инструмента, но большая идея состоит в том, что это будет использоваться в качестве общего API для запросов ЛЮБОГО источника данных, не просто RDBMS.

я не забываю читать, что linq, в то время как, очевидно, разработано с SQL в памяти, предназначен, чтобы быть языком запросов для любого хранилища данных. Можно записать запросы linq для SQL, но можно также теоретически записать запросы linq, которые предназначаются для ldap, файловой системы, обмен, веб-сервисы, до бесконечности. Вы не можете использовать SQL для тех программ.

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

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

я добавлю некоторые ссылки, если я могу найти их снова.

http://laribee.com/blog/2007/03/17/linq-to-entities-vs-nhibernate/

Необходимо прекратить волноваться и учиться любить ORM. Абстракции, такие как они помогут нам сфокусировать наши навыки и сделать усовершенствования в поле.

существует все еще много комнаты для использования в своих интересах функциональных навыков, Вы получили и применяете их на прикладном уровне. Это - на самом деле одни из преимуществ LINQ к SQL по другому ORM's.

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

то, Что не могло бы быть сразу очевидным, - то, что ORM идет со многими функциями, которые действительно хороши. Карта идентификационных данных, которая помогает постараться не загружать объекты много раз, ленивая загрузка, помогает Вам выразить домен меньшим количеством инфраструктуры, и единица работы помогает Вам отследить изменения и оптимизировать записи базы данных.

По моему скромному мнению, OR/M не только о 'абстракции SQL далеко' или сокрытии SQL или поддержки мульти-DBMS включения.

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

OR/M может быть мощным инструментом при использовании его правильно; это может заботиться о ленивой загрузке, полиморфные запросы / ассоциации...
не понимают меня превратно; нет ничего неправильно с простым SQL, но, если необходимо заботиться сами о переводе Вашего (хорошо мысль и нормализованный) реляционная модель к выразительному OO/модели предметной области, тогда я думаю, что Вы тратите путь к инфраструктуре выполнения большого количества времени.

Используя OR/M также не означает, что - как разработчик - необходимо не знать о SQL. Обратное верно, по моему скромному мнению.
SQL Знания и знание, как записать эффективный SQL-запрос, будут - по-моему-скромному-мнению, позволять Вам использовать OR/M правильно.

я должен также признать, что пишу это с NHibernate в памяти. Это - OR/M, что я использую банкомат, и я (еще) не привык Linq для SQL или Linq к объектам.

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

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

Как грубое сверхобобщение : Разработчики не знают SQL. Разработчики не делают действительно , хотят знать SQL. Они могут записать его, они могут разработать таблицы, но это заставляет их чувствовать себя неприглядными. Они имеют тенденцию делать глупые вещи, когда необходимый запрос является больше, чем простое соединение. Не потому что разработчики глупы - потому что они не могут быть побеспокоены. Они как проживание в мире, где они только должны иметь дело с одним пространством понятия; перемещение от объектов до таблиц и назад является контекстным переключением цена, за которую им не нравится платить.

Это не означает, что они плохи, или неправильно; это означает, что существует возможность для улучшения. Если Вашим клиентам (в этом случае, разработчики, использующие Вашу платформу), не нравится SQL, и таблицы - дают им слой абстракции, которая позволяет им уйти, не имея дело с базовой путаницей.

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

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

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

я не думаю, что "не бывший должный знать SQL" фактор. Любой достойный разработчик должен будет знать SQL в какой-то момент в их разработке. Идея уровня абстракции базы данных состоит в том, чтобы удалить усилие по генерации шаблонного кода для запросов базы данных.

Действительно в нашей системе в Java, я создал утилиту генератора кода, которая посещала аннотируемые уроки и генерировала полный API CRUD, и обрабатывающий все те изворотливые вещи, которые Вы берете со временем. Намного легче создать Вашу модель и аннотировать его, чем сильно ударить посредством записи ДАО. Увеличьте масштаб такого инструмента, и Вы заканчиваете с LINQ или В спящем режиме или несметное число другие решения для DB ORM.

Большинство людей упустили важный момент: в большинстве случаев вы значительно более продуктивны при запросах в LINQ, чем в SQL. Я написал статью о том, почему это так.

Когда я устанавливал LINQPad Challenge, я не шутил: я делаю почти все свои специальные запросы в LINQ, потому что большинство запросов могут быть написанным быстрее и надежнее в LINQ, чем в SQL. Я также разрабатывал и работал над крупными бизнес-приложениями, использующими LINQ to SQL, и увидел значительный рост производительности. Это не «астронавт архитектуры» - LINQ to SQL - это продуктивная и практичная технология, которая управляет этим самым сайтом .

Самым большим препятствием с LINQ является неспособность правильно его изучить. Я' Мы видели так много запросов LINQ, которые являются ужасной транслитерацией SQL-запросов, чтобы подтвердить это. Если вы пишете запросы LINQ, используя только ваши знания SQL, конечный результат может быть только таким же или даже хуже, чем SQL.

Я только что открыл этот вопрос. Наверное, он уже довольно сильно разыгран, но я все равно брошу свои два цента...

Я хочу писать код только для тех вещей, которые не очевидны.

Код CRUD очевиден. Я не хочу его писать. Поэтому, ORM - это хорошая идея.

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

ЛИНК также является хорошей идеей. Другие упоминали о некоторых преимуществах, но все, что мне нужно сделать, это подумать о первой попытке сделать поворот в LINQ, где я не знал заранее количество колонок. Или в первый раз я понял, что мне не нужно создавать новый DataView каждый раз, когда я хотел что-то отсортировать или отфильтровать. LINQ дает мне возможность делать все, что я хочу делать с данными на C#, вместо того, чтобы выяснять, как разделить работу между SQL и C#.

Итак, да, ORM, LINQ и другие развивающиеся технологии являются субоптимальными решениями, но они не упускают суть, и они не будут субоптимальными навсегда.