Начинаем строить слой доступа к данным. Что нужно учитывать? - PullRequest
4 голосов
/ 03 мая 2010

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

  • Datasets
  • ADO.net
  • Linq
  • Структура сущности
  • Дозвуковые
  • Другое

Некоторые учебники и статьи, которые я использовал для справки:

Я очень разорван, и мне очень трудно принять решение, по какому пути идти. Наш сайт представляет собой серию из 2 внутренних порталов и общедоступного веб-сайта. Мы используем vs2008 sp1 и версию 3.5.

Не могли бы вы дать мне совет о том, какие факторы следует учитывать, а также о плюсах и минусах, с которыми вы столкнулись на уровне доступа к данным.

PS. Я обнаружил, что информация о дозвуковом веб-сайте немного поверхностна, и большое внимание, кажется, уделяется тому, насколько «круто» оно и его разработчики. Я бы предпочел устное объяснение их демо-видео, чем музыку? Кто-нибудь еще согласен?

Ответы [ 4 ]

3 голосов
/ 03 мая 2010

Я бы предложил Entity Framework 4, если вы можете использовать .NET 4.0. Это хороший ORM, который будет только улучшаться с течением времени. Вы можете писать свои запросы, вставки и т. Д. С помощью Linq, который дает вам синтаксис, достаточно близкий к встроенному SQL, который вы используете сегодня. Очевидно, что за ним стоит MS, так что вы можете ожидать, что много информации и опытных разработчиков будут доступны сейчас и в будущем.

Если вам нужно остаться с .NET 3.5, я бы посмотрел на NHibernate. Он более зрелый, чем EF4, но в настоящее время ему не хватает полной поддержки Linq. Хотя вы сможете использовать Linq для относительно простых запросов, вам придется перейти на несколько менее похожий на SQL критерий API для более сложных запросов. Я бы также использовал Fluent NHibernate, чтобы разрешить настройку отображения в коде. Он пользуется сильной поддержкой сообщества и должен получить гораздо лучшую поддержку Linq в ближайшем будущем. Он также имеет то преимущество, что является открытым исходным кодом.

Любой из этих ORM позаботится о сопоставлении объектов вашей системы с базой данных. Это позволит вам сосредоточить больше усилий на построении логики приложения. По этой причине я бы не предложил использовать ADO.Net/Datasets. Linq2Sql довольно хорош для того, что он делает, но никогда не будет таким сильным, как Nhibernate или EF4. Linq2Sql всегда выглядел, как первая попытка MS, и, похоже, он играет второстепенную роль в Entity Framework.

2 голосов
/ 03 мая 2010
  1. Наборы данных> слишком много накладных расходов для того, что вы получаете. Как правило, это считается идеей, которая утратила свою популярность в день ее выпуска.

  2. ADO.Net (или Enterprise Library)> мои личные предпочтения по целому ряду причин. Однако мы никогда не используем встроенный sql по ряду других причин (в основном из-за безопасности), поэтому ваш пробег может отличаться. Одна из причин, по которой мы идем этим путем, заключается в том, что наша команда хорошо разбирается в SQL, и каждый из генераторов либо испытывает недостаток в производительности, либо вам нужно знать достаточное количество SQL для их настройки. При таком выборе мы решили сделать это сами.

  3. Linq> Пропустить это. Новая разработка в LINQ в основном остановлена, а ресурсы MS были перенесены в проект Entity Framework. Я также обнаружил многопоточность и другие проблемы в рамках, которые не были решены.

  4. Entity Framework> Некоторым людям это нравится. Вам все еще понадобится хорошее знание SQL, чтобы извлечь из этого максимум пользы.

  5. Дозвуковой и т. Д.> У вас недостаточно опыта со сторонними, чтобы действительно рассказать вам о плюсах / минусах.

Подводя итог, мы предпочитаем контроль и обладаем знаниями, чтобы извлечь из него максимум пользы. Мы пробовали маршрут linq / EF и не были впечатлены. Я видел других и кратко работал с ними, но они не смогли выполнить ничего, кроме самых простых операторов типа CRUD.

Если большая часть того, что вы делаете, связана с CRUD, то EF, Subsonic или similiar будут работать.

Некоторые вещи, которые следует учитывать при оценке:

  • Как он обрабатывает специальные запросы?
  • Как он справляется с подкачкой / сортировкой данных (на стороне SQL или перетаскивает все на веб-сервер)?
  • Какие утечки памяти?
  • Требуется ли многопоточность? Напишите простое приложение, чтобы проверить, что в каждом из тех, которые вы оцениваете. Запустите его много при разных условиях памяти / процессора.

Удачи.

2 голосов
/ 03 мая 2010

Не совсем легкое решение. Я ищу простоту и гибкость. Например, мне не очень нравится настраивать xml-файлы NHibernate; Мне не нравится, когда вырывается тонна кода Entity Framework; Я обеспокоен концом жизни linq-sql. Я не против наследования базового класса (некоторые люди хотят, чтобы объекты POCO были чистыми) для поддержки отображений Я также хочу иметь возможность переключать базы данных, не меняя мой код, просто меняя свою конфигурацию. Хороши и другие мелочи, такие как: возможность отображать результаты хранимых процедур на объекты; выбор поднабора столбцов по соображениям производительности; возможность при необходимости отправить чистый SQL-запрос.

1 голос
/ 04 мая 2010

Вопрос, который был сформулирован прямо сейчас, немного двусмысленный. «Уровень данных» может состоять из множества, многих, разных потребностей и желаний.

Я предполагаю, что SQL Server является резервной БД. Но это единственный? Насколько однороден уровень данных?

Вы просто ищете простой способ запрашивать и выводить данные? Или у вас есть потребность в полномасштабном решении для реляционного отображения объектов? У вас есть потребности, кроме запросов? Миграции и леса например?

Желаете ли вы или можете пожертвовать временем, чтобы освоить более сложные (но гибкие) наборы инструментов, такие как NHibernate или Subsonic?

Поработав с различной степенью сложности с EF, Linq to SQL, Subsonic и NHibernate, поначалу ни один из них не является "трудным" для начала, но поиск решений более сложных проблем или крайних случаев будет отличаться в зависимости от каждого. Можно утверждать, что EF и NH имеют наибольшее количество пользователей, и, таким образом, немного легко найти блоги / сообщения Stackoverflow, чтобы ответить на ваши вопросы. В этом отношении мне повезло больше с EF / NH. Тем не менее, Subsonic - это более доступная кодовая база, чтобы засучить рукава и решить ваши собственные проблемы (IMO).

Лично, после нескольких прогонов, я предпочитаю всегда начинать с того, что я считаю самым простым решением - Linq to SQL. Я считаю, что его барьер для входа является самым низким и наименее "инвазивным". Тем не менее, он сопровождается заметными ограничениями (такими как зависимость от сервера SQL). Но для быстрого и грязного, просто сделайте работу, это мое любимое, так как я бы не стал тратить слишком много времени на беспокойство о своем уровне данных. Только после того, как появятся требования, которые диктуют сдвиг, я рассмотрю возможность отойти - например, недавний проект, необходимый для чтения / записи в SQLite и SQL Server, и, таким образом, мы пошли без NH.

Понимание того, что вам действительно нужно, может помочь сформировать ответы от общих комментариев.

...