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

Я в настоящее время читаю при сохранении объектов в .NET. Как таковой я не могу предложить лучшую практику, но возможно мое понимание может принести Вам некоторое преимущество. Вплоть до несколько месяцев назад я всегда использовал запросы handcoded, дурную привычку с моих дней ASP.classic.

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

Платформа объекта - я играл вокруг с ним немного и не любил его. Это, кажется, хочет сделать все для меня, и это не работает хорошо с хранимыми процедурами. EF поддерживает Linq2Entities, который снова позволяет запросы со строгим контролем типов. Я думаю, что это ограничено MS SQL, но я мог быть неправым.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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