Я родом из Java.
Но я хотел бы кроссплатформенный взгляд на то, что считается лучшей практикой для сохраняющихся объектов.
Как я это вижу, есть 3 лагеря:
Люди до сих пор вручную кодируют запросы (в обход ORM)? Почему, учитывая варианты, доступные через JPA, Django, Rails.
Не существует единственной наилучшей практики сохранения (хотя количество людей, кричащих, что ORM — это лучшая практика, может заставить вас поверить в обратное). Единственной лучшей практикой является использование метода, наиболее подходящего для вашей команды и вашего проекта.
Мы используем ADO.NET и хранимые процедуры для доступа к данным (хотя у нас есть некоторые вспомогательные средства, которые позволяют очень быстро писать, такие как генераторы оболочки классов SP, транслятор IDataRecord для объектов и некоторые процедуры более высокого порядка, инкапсулирующие общие шаблоны и обработку ошибок) .
Для этого есть множество причин, которые я не буду здесь описывать, но достаточно сказать, что это решения, которые работают для нашей команды и с которыми наша команда согласна. Что, в конце концов, и важно.
В настоящее время я читаю о сохраняющихся объектах в .net. Таким образом, я не могу предложить лучшую практику, но, возможно, мои идеи могут принести вам некоторую пользу. Еще несколько месяцев назад я всегда использовал запросы, написанные вручную, — плохая привычка со времен ASP.classic.
Linq2SQL — очень легкий и простой в использовании. Мне нравятся возможности строго типизированных запросов и тот факт, что SQL не выполняется сразу. Вместо этого он выполняется, когда ваш запрос готов (все фильтры применены), таким образом, вы можете разделить доступ к данным от фильтрации данных. Кроме того, Linq2SQL позволяет мне использовать объекты предметной области, которые отделены от объектов данных, которые генерируются динамически. Я не пробовал Linq2SQL в более крупном проекте, но пока это кажется многообещающим. О, он поддерживает только MS SQL, что очень жаль.
Entity Framework. Я немного поэкспериментировал с ним, и он мне не понравился. Кажется, он хочет сделать все за меня и плохо работает с хранимыми процедурами. EF поддерживает Linq2Entities, что опять-таки допускает строго типизированные запросы. Я думаю, что это ограничено MS SQL, но я могу ошибаться.
SubSonic 3.0 (альфа) — это более новая версия SubSonic, которая поддерживает Linq. Самое классное в SubSonic то, что он основан на файлах шаблонов (шаблоны T4, написанные на C#), которые вы можете легко модифицировать. Таким образом, если вы хотите, чтобы автоматически сгенерированный код выглядел иначе, просто измените его :). Я пока пробовал только предварительный просмотр, но сегодня посмотрю на альфу. Посмотрите здесь SubSonic 3 Alpha. Поддерживает MS SQL, но скоро будет поддерживать Oracle, MySql и т.д.
На данный момент мой вывод состоит в том, чтобы использовать Linq2SQL до тех пор, пока SubSonic не будет готов, а затем переключиться на него, поскольку шаблоны SubSonics позволяют гораздо больше настроек.
Есть как минимум еще один: Системная распространенность.
Насколько я могу судить, то, что является оптимальным для вас, во многом зависит от ваших обстоятельств. Я понял, что для очень простых систем использование прямых запросов все еще может быть хорошей идеей. Кроме того, я видел, что Hibernate плохо работает со сложными устаревшими схемами базы данных, поэтому использование ORM не всегда может быть допустимым вариантом. Предполагается, что System Prevalence работает невероятно быстро, если у вас достаточно памяти, чтобы разместить все ваши объекты в оперативной памяти. Не знаю о LINQ, но я полагаю, что он тоже имеет свое применение.
Итак, как это часто бывает, ответ таков: знайте множество инструментов для работы, чтобы иметь возможность использовать тот, который наиболее подходит для вашей конкретной ситуации.
Лучшая практика зависит от вашей ситуации.
Если вам нужны объекты базы данных в табличных структурах с какой-то значимой структурой (например, один столбец на поле, одна строка на сущность и т. д.), вам нужен какой-то уровень перевода между объектами и базой данных. Они делятся на два лагеря:
Если в базе данных нет логики (только хранилище) и таблицы хорошо сопоставляются с объектами, то решение ORM может обеспечить быструю и надежную систему сохранения. Системы Java, такие как Toplink и Hibernate, являются зрелыми технологиями для этого.
Если в сохранении есть логика базы данных, или схема вашей базы данных значительно отклонилась от вашей объектной модели, хранимые процедуры, обернутые объектами доступа к данным (с дополнительными шаблонами, как вам нравится), немного сложнее, чем ORM. но более гибкий.
Если вам не нужно структурированное хранилище (и вы должны быть действительно уверены, что оно вам не нужно, поскольку вводить его в существующие данные неинтересно), вы можете хранить сериализованные графы объектов непосредственно в базе данных. , обходя много сложностей.
Я предпочитаю писать свой собственный SQL, но при этом применяю все свои методы рефакторинга и другие «хорошие вещи».
Я написал уровни доступа к данным, генераторы кода ORM, уровни сохраняемости, управление транзакциями UnitOfWork и МНОГО SQL. Я делал это в системах всех форм и размеров, включая чрезвычайно высокопроизводительные потоки данных (сорок тысяч файлов, в общей сложности сорок миллионов транзакций в день, каждый из которых загружается в течение двух минут в режиме реального времени).
Наиболее важным критерием является судьба, как контроль над ней. Никогда не позволяйте вашему ORM-инструменту стать препятствием для выполнения вашей работы или оправданием того, что вы делаете что-то не так. В конечном счете, весь хороший SQL пишется и настраивается вручную, но некоторые достойные инструменты могут помочь вам быстро получить хороший первый черновик.
Я отношусь к этой проблеме так же, как к своему дизайну пользовательского интерфейса. Я пишу все свои пользовательские интерфейсы непосредственно в коде, но я могу использовать визуального дизайнера для прототипирования некоторых важных элементов, которые я имею в виду, а затем я разбиваю сгенерированный им код, чтобы запустить свой собственный.
Итак, используйте инструмент ORM в любом его проявлении, чтобы получить достойный пример — посмотрите, как он решает многие возникающие проблемы (генерация ключей, ассоциации, навигация и т. д.). Разорвите его вывод, сделайте его своим, а затем повторно используйте его, черт возьми.
