Является ли LINQ объектно-реляционным картографом?

Question

Является ли LINQ своего рода объектно-реляционным картографом?

Answer 1

LINQ сам по себе является набором языковых расширений, которые облегчают запросы, читаемость и сокращают код. LINQ to SQL - это своего рода OR Mapper, но он не особенно мощный. Entity Framework часто называют OR Mapper, но он довольно много more .

Существует несколько других реализаций LINQ to X , в том числе LINQ to NHibernate и LINQ to LLBLGenPro , которые предлагают OR Mapping и поддержку каркасов в целом аналогично Entity Framework.

Если вы только изучаете LINQ, я бы порекомендовал вам LINQ to Objects , чтобы почувствовать его, а не углубляться в один из более сложных ароматов: -)

Answer 2

LINQ вовсе не ORM. LINQ - это способ запроса «материала», и его можно более или менее рассматривать как расширение языка, похожее на SQL, для разных вещей (IEnumerables).

Существуют различные типы «вещей», к которым можно обращаться, в том числе базы данных SQL Server. Это называется LINQ-to-SQL. Он работает так, что генерирует (неявные) классы на основе структуры БД и вашего запроса. В этом смысле он работает гораздо больше, как генератор кода.

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

LINQ-to-SQL ничего подобного не делает. Ваши запросы LINQ будут тесно связаны со структурой базы данных. Если вы измените БД, вам, вероятно, придется изменить и LINQ.

Answer 3

Я думаю, что хороший тест для определения того, отображает ли платформа или кодовый блок характеристики O / R-M, просто:

Имеет ли разработчик (-и) (или его / ее генератор кода) какие-либо прямые, беспрепятственные знания о том, что находится внутри базы данных?

С этим критерием ответ для различных реализаций LINQ может быть

Да, знание схемы базы данных целиком и полностью содержится в LINQ с использованием уровня кода O / R-M

или

Нет, знание схемы базы данных разбросано по всему приложению

Кроме того, я бы расширил эту характеристику до трех простых уровней O / R-M.

1. Оставление.

Это небольшое приложение с парой разработчиков, и модель объекта / данных не так сложна и не очень часто меняется. Небольшая команда разработчиков может остаться на вершине.

2. Сверните свое собственное в слой доступа к данным.

При некотором управляемом рефакторинге на уровне доступа к данным желаемая функциональность O / R-M может быть реализована на промежуточном уровне относительно небольшой группой разработчиков. Достаточно, чтобы вся команда была на одной странице.

3. Спецификации O / R-M уровня предприятия, определяющие / накладные вводные инструменты.

На некотором уровне сложности необходимость держать всех разработчиков на одной странице просто перекрывает любые накладные расходы, связанные с формальностью. Не нужно изобретать велосипед на этом уровне сложности. N-hibernate или (грубый) V1.0 Entity Framework являются примерами такого масштаба.

Более богатую классификацию, которую я заимствовал и упростил, см. В классической публикации Теда Ньюарда по адресу

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

где он классифицирует О / Р-М лечение (или отречение) как

1. Оставление.

Разработчики просто полностью отказываются от объектов и возвращаются к модели программирования, которая не создает несоответствия между объектами и реляционным импедансом. Хотя это неприятно, в определенных сценариях объектно-ориентированный подход создает больше накладных расходов, чем экономит, а окупаемость инвестиций просто не позволяет оправдать затраты на создание модели с расширенным доменом. ([Фаулер] говорит об этом немного глубже.) Это решает проблему довольно аккуратно, потому что, если нет объектов, нет и несоответствия импеданса.

2. Искреннее принятие.

Разработчики просто полностью отказываются от реляционного хранилища и используют модель хранилища, которая соответствует тому, как их языки смотрят на мир. Системы хранения объектов, такие как проект db4o, решают проблему аккуратно, сохраняя объекты непосредственно на диске, устраняя многие (но не все) из вышеупомянутых проблем; например, «второй схемы» не существует, поскольку единственной используемой схемой является схема самих определений объектов. В то время как многие администраторы баз данных упадут в обморок от этой мысли, в мире, который все больше ориентируется на сервис, который отказывается от идеи прямого доступа к данным, но вместо этого требует, чтобы весь доступ проходил через сервисный шлюз, таким образом инкапсулируя механизм хранения от любопытных глаз, он становится полностью Можно представить, что разработчики хранят данные в форме, которую им гораздо проще использовать, чем администраторам баз данных.

3. Ручное картирование.

Разработчики просто признают, что в конце концов это не так сложно решить вручную, и пишут прямой код реляционного доступа, чтобы возвращать отношения к языку, получать доступ к кортежам и заполнять объекты по мере необходимости. Во многих случаях этот код может даже автоматически генерироваться инструментом, исследующим метаданные базы данных, что устраняет некоторые основные критические замечания этого подхода (а именно: «Это слишком много кода для написания и поддержки»).

4. Принятие ограничений O / R-M.

Разработчики просто признают, что не существует способа эффективно и легко замкнуть цикл при несовпадении O / R, и используют O / RM для решения 80% (или 50%, или 95%, или любого процента, который кажется подходящим) проблема и использовать SQL и реляционный доступ (такой как «сырой» JDBC или ADO.NET), чтобы перенести их в те области, где O / RM может создать проблемы. Однако это несет свою долю риска, поскольку разработчики, использующие O / RM, должны знать о любом кэшировании решения O / RM внутри него, поскольку «сырой» реляционный доступ явно не сможет воспользоваться преимуществами этот слой кэширования.

5. Интеграция реляционных понятий в языки.

Разработчики просто признают, что это проблема, которая должна решаться языком, а не библиотекой или структурой. В течение последнего десятилетия акцент на решениях проблемы O / R был сосредоточен на попытках приблизить объекты к базе данных, чтобы разработчики могли сосредоточиться исключительно на программировании в одной парадигме (эта парадигма, конечно, является объектами). ). Однако в последние несколько лет интерес к языкам «сценариев» с гораздо более сильной поддержкой наборов и списков, таким как Ruby, породил идею о том, что, возможно, уместно другое решение: принести реляционные концепции (которые, в основе своей, основаны на наборах) в основные языки программирования, упрощая преодоление разрыва между «множествами» и «объектами». Работа в этом пространстве до сих пор была ограничена, в основном ограничена исследовательскими проектами и / или «незначительными» языками, но в сообществе появляется несколько интересных усилий, таких как функционально-объектные гибридные языки, такие как Scala или F #, а также прямые интеграция в традиционные языки OO, , такие как проект LINQ от Microsoft для C # и Visual Basic . К сожалению, одной из таких попыток была неудачная стратегия SQL / J; даже в этом случае подход был ограничен: он не пытался включить наборы в Java, а просто позволял выполнять предварительную обработку встроенных вызовов SQL и переводить их в код JDBC с помощью переводчика.

6. Интеграция реляционных понятий в рамки.

Разработчики просто признают, что эта проблема разрешима, но только с изменением перспективы. Вместо того чтобы полагаться на разработчиков языка или библиотеки для решения этой проблемы, разработчики придерживаются иного взгляда на «объекты», которые являются более реляционными по своей природе, создавая доменные структуры, которые более непосредственно построены вокруг реляционных конструкций. Например, вместо создания класса Person, который хранит свои данные экземпляра непосредственно в полях внутри объекта, разработчики создают класс Person, который хранит свои данные экземпляра в экземпляре RowSet (Java) или DataSet (C #), который может быть собран с другими RowSets / DataSets в простой в отправке блок данных для обновления базы данных или распаковки из базы данных в отдельные объекты.

Answer 4

LINQ сам по себе не является ORM. LINQ - это языковые функции и методы, которые позволяют вам запрашивать такие объекты, как SQL.

«LINQ to SQL» - поставщик, который позволяет нам использовать LINQ против объектов со строгой типизацией SQL.

Answer 5

LINQ to SQL (часть Visual Studio 2008) является OR Mapper.

LINQ - это новый язык запросов, который можно использовать для запросов к различным типам источников.

Answer 6

Linq Для SQL с помощью конструктора dbml yes, в противном случае Linq - это просто набор методов расширения для перечисляемых.