Блог

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

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

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

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

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

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

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

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

LINQ to SQL (часть Visual Studio 2008) — это сопоставитель ИЛИ.

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

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

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

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

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

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

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

или

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

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

1. Заброшенность.

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

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

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

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

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

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

http://blogs.tedneward.com/2006/06/26/The Вьетнам Из Информатики Науки.aspx

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

1. Заброшенность.

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

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

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

3. Ручное отображение.

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

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

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

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

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

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

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

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