Что бы вы выбрали, если бы вы могли использовать любую технологию .NET DAL?

Question

Через пару лет я возвращаюсь к разработке .NET, и, похоже, теперь, особенно с LINQ, способ доступа к вашим данным изменился и стал намного проще. Например, на веб-сайте ASP.NET MVC я могу:

• Добавить товар
• добавить классы LINQ-to-SQL
• перетащите таблицы базы данных в конструктор реляционных объектов LINQ-to-SQL, нажмите кнопку Сохранить
• доступ и манипулирование моими данными через LINQ однострочников (что я узнал здесь: http://www.asp.net/learn/mvc/tutorial-11-cs.aspx)

Это выглядит великолепно, но насколько это реально?

• - это приведенный выше сценарий LINQ-to-SQL, который вы используете в реальных проектах, или это просто быстрая технология скаффолдинга, т.е. что происходит, когда вы начинаете добавлять, удалять поля и таблицы в вашей базе данных, как это делает LINQ-to -SQL классы остаются в синхронизации?

А как мне понять все новые технологии в этом пространстве, например,

• Где подходит Subsonic?
• Где подходит Astoria (ADO.NET Data Services)?
• Где вписывается NHibernate?
• Как я могу использовать другие базы данных с LINQ-to-SQL (я попытался перетащить таблицу SQLite в Object Relational Designer и получил сообщение «ошибка не поддерживается) или LINQ-to-SQL только для SQL Server?
• работает ли LINQ-to-XML так же, как LINQ-to-SQL, например я могу перетащить XML-файлы в конструктор и затем получить к ним доступ через LINQ, или мне нужно написать собственный код для этого?

• работает ли LINQ-to-Entities как LINQ-to-SQL, то есть автоматически генерируемые классы, но только с большим количеством опций?

• Является ли ADO.NET с его DataTables и DataSets старой технологией теперь, когда у нас есть LINQ? Имеет ли смысл LINQ-to-ADO.NET?

• где подходит Azure, где у вас даже нет RDBMS

• где ESB подходит, когда ваш пользовательский интерфейс просто RESTful общается с WCF или общается с веб-службами?

Теперь, когда у нас так много вариантов, если бы вы могли выбрать любую из этих технологий для проекта, что бы вы выбрали и почему?

Answer 1

Первоначальные ответы (в основном на материал LINQ):

• LINQ to SQL - это то, что вы можете использовать в реальных проектах; Я сделал. Как правило, мы имеем весь наш код доступа к данным в частичном классе, который генерируется, когда вы щелкаете правой кнопкой мыши по области конструктора и выбираете «Просмотреть код», а не разбросаны по всему тексту в виде одной строки.
• При использовании LINQ to SQL, если вы изменяете базу данных, вам нужно удалить и повторно добавить таблицы - это небольшое ограничение, с Entity Framework вы можете «Обновить модель из базы данных», чтобы автоматически добавлять / удалять эти столбцы.
• Вероятно, он должен был называться LINQ to MSSQL Server - он напрямую связан с SQL Server. Если вы хотите использовать подобный инструментарий с другими источниками данных, вы можете взглянуть на Entity Framework - однако в настоящее время у него есть другие ограничения - LINQ to SQL - это всего лишь доказательство того, что это может работать.
• Службы данных ADO.NET предоставляют вам интерфейс на основе REST к вашим объектам ADO.NET, так что вы можете вызывать простые веб-службы для извлечения данных без необходимости писать эти службы.
• Нет, для LINQ to XML нет области разработки - я думаю, что кто-то мог бы что-то сделать с XSD, хотя это было бы интересно;)
• Вы можете думать о Azure как о «операционной системе в облаке», у нее есть база данных для хранения, хотя, как вы заявляете, она не реляционная, нет соединений, но вы все равно будете запрашивать ее для получения результатов. .

Чтобы ответить на ваш последний вопрос, я недостаточно узнал о NHibernate или других, чтобы сказать, но я был бы рад использовать LINQ to SQL для базового доступа к базе данных, но я начал смотреть на LINQ to Entities для моего более сложные вещи, чем другие - в основном потому, что мне нравятся красивые картинки.

Answer 2

Относительно SQLite : я успешно использовал dbLinq для построения запросов LINQ к базе данных SQLite. Это все еще в зачаточном состоянии, так что ожидайте исправить некоторые вещи в сгенерированных классах, но это сработало для моих нужд. Это будет делать, я думаю, 85% всех вещей, которые будет делать LinqToSql. И есть множество модульных тестов в проекте, чтобы сказать вам, что они знают, что терпит неудачу.

dbLinq поддерживает множество других баз данных (MySQL, PostgreSQL, Firebird). Я не использовал его ни для чего, кроме SQLite.

Answer 3

Мне просто нужно было ответить на тот же вопрос для нового проекта, который мы начинаем, и после сравнения альтернатив мы выбрали LLBLGen , потому что:

• Он более зрелый, чем Entity Framework
• Поддерживает запросы Linq
• Он активно разрабатывается несколькими разработчиками
• Это недорого
• Поддержка просто отличная

пс. Вероятно, я должен упомянуть, что я не связан с проектами llblgen и / или решений.

Answer 4

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

Одно предостережение: varchar (1) по умолчанию конвертируется в char. Это доставило мне неприятности, потому что varchar (1) может быть "", тогда как char не может ... Простой переход к строке в окне свойств решил эту проблему.