Какова лучшая практика для настойчивости прямо сейчас?

Я пришел из происхождения Java.

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

На мой взгляд, есть 3 лагеря:

  • ORM лагерь
  • лагерь прямых запросов, например, JDBC / DAO, iBatis
  • Лагерь LINQ

Люди все еще запрашивают код (в обход ORM)? Почему, учитывая варианты, доступные через JPA, Django, Rails.

12.12.2008 10:19:57
5 ОТВЕТОВ
РЕШЕНИЕ

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

Мы используем ADO.NET и хранимые процедуры для доступа к данным (хотя у нас есть некоторые помощники, которые очень быстро пишут, такие как генераторы оболочек классов SP, IDataRecord для транслятора объектов и некоторые процедуры более высокого порядка, инкапсулирующие общие шаблоны и обработку ошибок) ,

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

6
12.12.2008 12:26:15

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

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

Entity Framework - я немного поиграл с этим и мне не понравилось. Кажется, что хочет сделать все для меня, и это не работает с хранимыми процедурами. EF поддерживает Linq2Entities, что снова позволяет строго типизированные запросы. Я думаю, что это ограничено MS SQL, но я могу ошибаться.

SubSonic 3.0 (Alpha) - это более новая версия SubSonic, которая поддерживает Linq. Отличительной особенностью SubSonic является то, что он основан на файлах шаблонов (шаблоны T4, написанных на C #), которые вы можете легко изменить. Таким образом, если вы хотите, чтобы автоматически сгенерированный код выглядел иначе, просто измените его :). Я только попробовал предварительный просмотр пока, но посмотрю на Альфу сегодня. Посмотрите здесь SubSonic 3 Alpha . Поддерживает MS SQL, но скоро будет поддерживать Oracle, MySql и т. Д.

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

3
12.12.2008 11:33:34
Re: EF ограничивается MS SQL - из коробки - да, но есть сторонние партнеры, разрабатывающие поставщиков для других RDBMS. Так, например, если вы хотите ORACLE, то компания DevArt имеет как поставщика EF для ORACLE, так и реализацию LINQ-to-ORACLE.
rohancragg 28.06.2009 11:58:31

Существует, по крайней мере, еще один: системная распространенность .

Насколько я могу судить, то, что для вас оптимально, во многом зависит от ваших обстоятельств. Я мог видеть, как для очень простых систем использование прямых запросов все еще может быть хорошей идеей. Кроме того, я видел, что Hibernate не может хорошо работать со сложными, устаревшими схемами базы данных, поэтому использование ORM не всегда может быть допустимым вариантом. Предполагается, что система превалирует без перерыва, если у вас достаточно памяти для размещения всех ваших объектов в оперативной памяти. Не знаю насчет LINQ, но я полагаю, что он тоже имеет применение.

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

3
12.12.2008 19:25:32
распространенность системы неверно предполагает, что если вы сможете разместить все свои объекты в оперативной памяти, она будет работать быстро. ну не будет. есть сообщения, что даже современные сборщики мусора сходят с ума, когда им приходится обрабатывать миллионы объектов. также в наши дни, если у вас достаточно памяти на сервере баз данных, вы получаете аналогичную и зачастую даже более высокую производительность, чем при использовании распространенности системы, поскольку базы данных оптимизированы для производительности, а язык общего назначения и сборщик мусора - нет.
lubos hasko 7.02.2010 23:42:35

Лучшая практика зависит от вашей ситуации.

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

  • Если в базе данных нет логики (только хранилища) и таблицы хорошо отображаются на объекты, то решение ORM может обеспечить быструю и надежную систему персистентности. Системы Java, такие как Toplink и Hibernate, являются зрелыми технологиями для этого.

  • Если есть логика базы данных участвует в настойчивости, или ваша схему базы данных отнесли от объектной модели значительно, хранимые процедуры , обернутые доступ к данным объектов (с последующими узорами , как вам нравится) немного сложнее, чем ОРМ , но более гибкий.

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

2
12.12.2008 14:21:12
Re: первый лагерь, я не согласен, что легче с решением ORM. В системе сборки много настроек, чтобы она работала правильно.
ashitaka 14.12.2008 12:55:12

Я предпочитаю писать свой собственный SQL, но при этом я применяю все свои методы рефакторинга и другие «хорошие вещи».

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

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

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

Итак, используйте инструмент ORM в любом его проявлении, чтобы получить достойный пример - посмотрите, как он решает многие возникающие проблемы (генерация ключей, ассоциации, навигация и т. Д.). Разбейте его на части, сделайте его своим, а затем снова используйте его.

2
16.12.2008 00:40:43
Роб, спасибо за ваши комментарии. Это очень поучительно. Я также предпочитаю писать свой собственный SQL. Но почти во всех проектах, в которые я вступаю, они предпочитают использовать ORM. Вы упомянули ту систему с 40 миллионами транзакций в день, на какой платформе она работала?
ashitaka 16.12.2008 06:50:37
База данных Oracle 10g на 8 ТБ в SAN, Sun Solaris 10 на среднестатистической коробке SunFire с 4 ГБ ОЗУ, Java 1.6, предоставляемая через веб-сервис на JBoss & WebLogic 10
Rob Williams 16.12.2008 21:37:53