Какой ваш любимый способ взаимодействия с базами данных на вашем языке программирования?

Я предпочитаю создавать слой модели бизнес-объектов (объекты и совокупности объектов).

Я встраиваю возможность взаимодействия с базой данных в каждый объект / коллекцию (для SQL Server я использую System.Data.SqlClient). Я использовал этот шаблон для SQL Server, MySQL и Oracle.

Затем я взаимодействую с объектами из кода моего приложения.

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

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

LINQ - это то, что мне нужно

Мне очень нравится подход «3 + 1». Один уровень для пользовательского интерфейса, один для бизнес-логики и для сохраняемых данных. Последнее, что вы говорите? Объекты и интерфейсы предметной области. Это позволяет загрузить один или два основных уровня плюс домен «уровень», и код должен работать.

Он в значительной степени полагается на принципы внедрение зависимости и Инверсия контроля. Уровень данных / сохраняемости выполняет только две функции. Он создает, читает, обновляет и удаляет данные и сопоставляет их с форматом объекта домена.

Уровень пользовательского интерфейса делает прямо противоположное. Он отображает и принимает данные таким образом, чтобы пользователь мог иметь отношение к ним, и сопоставляет этот вывод / ввод с форматом объекта домена и из него.

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

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

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

</rant>

Обновлено: О да. Это верно как для LINQ, SubSonic, так и для других ORM.

ORM действительно фантастический.

Я использую SQL Alchemy при работе с python - она ​​работает практически со всеми СУБД, с которыми мне приходилось сталкиваться.

Для легких приложений, управляемых данными, в MacOS X я использую Core Data, в котором есть отличный инструмент моделирования данных, доступный через Xcode.

Оба они показывают, что ORM, выполненный правильно, превосходен. У меня было меньше успеха и удовольствия от EJB.

Я еще не вошел в мир LINQ, но мне очень понравились классы DataTable / TableAdapter, которые Visual Studio сделала с помощью набора данных XSD. С помощью нескольких перетаскиваний и щелчков мышью после создания схемы базы данных у меня теперь есть строго типизированный объект DataSet / DataTable и методы адаптера, которые используют параметризованные запросы к моим хранимым процедурам для всех моих операторов CRUD. Он даже создаст адаптеры таблиц запросов для некоторых из тех процедур, которые напрямую не привязаны к таблице.

Да, и если вы еще не создали хранимые процедуры и у вас есть только таблицы, мастер создаст для вас процедуры или специальные операторы SQL.

Он отсутствовал с Visual Studio 2005 и резко сократил мое «структурное» время с моими новыми веб-приложениями, и я могу больше сосредоточиться на бизнес-логике и логике представления.

В C# я люблю LINQ to SQL за все новое, но мне очень нравится использовать .netTiers + Генератор CodeSmith, чтобы получить быстрый и грязный уровень данных в базе данных, если я использую C# в .NET 2.0.

ActiveRecord Ruby on Rails стирает пол со всем остальным, что я видел до сих пор. LINQ в некоторых случаях может быть лучше, но ActiveRecord настолько гибок.

Мне очень нравится Спящий режим :)

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

Излишне говорить, что мне не терпится получить в свои руки новый Entity Framework в .NET 3.5 SP1 (я знаю, что он уже доступен, но мне немного лень вводить XML :))

ActiveRecord, который является шаблоном, задокументированным первым (я думаю) в Паттерны архитектуры предприятия Фаулера. Я считаю, что он реализован не на Ruby, а на других языках, хотя он хорошо известен как основная технология в Rails. Как бы то ни было, это аккуратная абстракция базы данных, хотя я должен признаться, что нахожу ее немного неуклюжей и в области find_by_sql. Но это может быть только я.

Но (надев теперь шляпу Grumpy Old Man) все ORM в мире не заменят хорошего знания SQL, без чего мне действительно не нравится, когда доступ к СУБД вообще разрешен.

В настоящее время мы используем ODAC для общения с базой данных Oracle и используем множество пакетов Oracle (PL / SQL). Многоуровневая система реализована с помощью RemObjects, что означает, что у нашего клиента нет никакого SQL, и ему нужна только возможность отправлять HTTP-запросы, поэтому нет накладных расходов на установку.

Все это делается с использованием Borland Delphi и работает уже 2 года в производственной среде.

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

• При чтении информации на странице для отображения и для обновления пользователем мы используем Hibernate.
• При обработке пакета обновлений или суммировании того, где большая часть данных уже находится в базе данных (например, обработка в конце дня), мы используем PL / SQL (и пытаемся мыслить наборами)
• Когда пользователь выполняет поиск или запускает сводный отчет, мы используем ibatis sqlmaps для создания некоторого SQL и возврата только тех полей, которые нам интересны (не каждый столбец и, конечно, не ненужные дочерние строки, urggh)
• Все, что действительно должно работать быстро, мы будем использовать любой подход, который работает лучше всего.

Это с java / Oracle.

Мы используем компоненты доступа к данным Delphi и Oracle (ODAC) и ADO через Oracle.OleDBProvider.

Самый любимый способ - использовать Smalltalk с репозиторием объектов GemStone. Почему? Нет проблем с ORM. Я бы рассмотрел что-то другое, только если бы мой работодатель принуждал или угрожал.

Мой любимый способ - создать слой абстракции объекта. В идеале это место Только, которое работает с SQL. Но на практике объекты иногда тоже должны выполнять SQL-y. Но ничего вне объекта.

До сих пор я сам писал такие слои, потому что то, что было доступно, было слишком неудобным, слишком медленным или слишком большим.

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