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

Question

Я родом из Java-фона.

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Я сейчас читаю о сохраняющихся объектах в .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 позволяют гораздо больше настроек.

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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