Лучшие практики применения баз данных в .Net

Question

В 2003 году я начал создавать веб-приложения, использующие базы данных на PHP. Конечно, я начал с того, что просто помещал SQL-запросы непосредственно в мой код, не используя хранимые процедуры, подготовленные операторы или какую-либо среду ORM. Но тогда это была обычная практика, о чем свидетельствует код, над которым я работаю сегодня (веб-приложение VB.Net, созданное примерно в то время).

Приложение использует около десятка хранимых процедур, несколько подготовленных операторов и множество SQL-запросов непосредственно в коде. Как правило, существуют избыточные блоки кода, которые получают соединение, выполняют запрос SQL (строку), а затем используют средство чтения для извлечения данных с использованием жестко закодированных имен полей. Сейчас 2011 год, написание такого рода кода было легко и потому популярно в 2003 году, но я полагаю, что это не лучшая практика. Он небезопасен или не прост в обслуживании, и я не касался хранимых процедур.

Я хочу выйти за рамки жесткого кодирования SQL-запросов в приложениях и ручного анализа данных из ответов. Каковы текущие лучшие практики и инструменты для создания приложений баз данных в .Net? Я слышал о Linq2SQL, Entity Framework, NHibernate и некоторых других технологиях, но я не знаю, когда их следует использовать или они все еще актуальны.

Я использую Visual Studio 2010, VB / C # и SQL Server 2008 Express

Edit: похоже, что большинство из вас обсуждают программное обеспечение ORM. Это звучит как то, что я хочу; у нас есть несколько таблиц с большим количеством информации, которая может быть доступна как объект. Когда я должен вместо этого использовать стандартный запрос или подготовленный оператор?

Answer 1

Entity Framework и NHibernate - это так называемые объектные / реляционные картографы. Оба они создают слой, который устраняет разрыв между объектами и базами данных (иногда называемый Несоответствие реляционного импеданса объекта ).

Я не могу рекомендовать использовать OR / M достаточно. Либо один хорош; NHibernate имеет некоторое преимущество в безопасности, но, похоже, имеет более крутой кривой обучения. Я лично использую Entity Framework, но это действительно вопрос предпочтений.

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

LINQ2SQL - это более ориентированная на базы данных технология, но она квалифицируется как OR / M. Я бы пропустил прямо к EF. EF был частью .Net 3.5 SP1, найден здесь .

Вот пример кода для извлечения клиента из базы данных с использованием EF:

using (var ctx = new DBEntities())
{
     var employee = (from e in ctx.Employees
            where e.User.UserName == userName
            select e).FirstOrDefault();
}

Другая причина использования OR / M, на мой взгляд, заключается в том, что они имеют тенденцию продвигать дизайнерское представление вашего кода как первоклассный артефакт. Под этим я подразумеваю то, что у вас получилось хорошее графическое представление об отношениях между вашими сущностями (потому что редактор - это перетаскивание), от которого вы не откажетесь, когда у вас не хватит времени.

Вот ссылка MS по началу работы: http://msdn.microsoft.com/en-us/library/bb386876.aspx.

НТН.

Answer 2

Попробуйте LLBLGen: http://www.llblgen.com/defaultgeneric.aspx

Они имеют простой пользовательский интерфейс, который позволяет вам указывать на вашу БД и мгновенно генерировать для вас весь DAL за считанные минуты.Настройка и интеграция были намного проще, чем у любого другого продукта ORM, который я видел.Это также настраиваемо, но я все еще не так много сделал с настройкой.Нужно узнать больше информации там.

Answer 3

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

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

NHibernate

Проект с открытым исходным кодом, основанный на Java Hibernate проекте.Он очень активен и имеет отличную поддержку для ряда сценариев.

LINQ to SQL

Хотя он официально не мертв, он был опубликован публичнозаявил, что основное внимание в разработке не будет в LINQ-to-SQL.Эти усилия будут направлены на LINQ-to-Entities.Хотя в целом лучше работать с LINQ to Entities (если выбирать между этим и тем), существуют проблемы;генерация моделей не так чиста, как хотелось бы некоторым, модель отображения метаданных, которую они используют, не позволяет легко использовать модели от разных дизайнеров , и другие проблемы, которые NHibernate, вероятно, уже давно преодолел.

LINQ to Entities

В настоящее время предпочтительный метод доступа к данным в .NET (о чем свидетельствует не только поддержка дизайнера и интеграция в VS.NET, но в таких средах, как RIA), это то, чему MS будет посвящать энергию при работе с пространством ORM.В настоящее время он проходит вторую крупную итерацию (первую из которых трудно использовать несколько человек), простота использования определенно возросла.

Я также буду искать будущие интеграции с другими технологиями MS..

---

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

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