ORM собственной разработки по сравнению с DataTables?

Я одобряю DataTables путь, потому что я являюсь старым, усталым, и скептически отношусь к видам как Subsonic и Linq.

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

Используя Наборы данных, я могу сделать что-то как:

выберите col1, col2... от table1
выберите col1, col2... от table2
выберите col1, col2... от table3

и затем совершите ОДНУ поездку в базу данных для получения всех трех DataSets, с помощью Таблиц [0], Таблицы [1], Таблицы [2] для ссылки на них. Это имеет очень большую разницу в производительности.

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

Наконец, мне нравится SQL. Я способен к SQL. Очень хороший. Я не хочу проводить свое время, выясняя, как принудить Linq для испускания SQL, который я хочу. Это замедлило бы МОЮ производительность.

Вы могли объединиться, оба подхода упомянули, что использовали DataSets Со строгим контролем типов.

Возможно добавить их к проекту Visual Studio через то, "Добавьте Новый Объект" диалоговый "Шаблон DataSet" и затем используйте визуального Разработчика Набора данных (это редактирует файл XSD негласно).

Существует другая статья о предмете.

В .NET наборы данных со строгим контролем типов обладают преимуществами, которые Вы приписываете ORM - значение строгого контроля типов в IDE и Intellisense,

TableAdapters, созданный в Visual Studio, запишет весь Ваш SQL CRUD для Вас. Вы помещаете свою бизнес-логику в C# (или другой Ленг.) а не в SQL.

Я думаю, что разъединенная модель данных, предлагаемая наборами данных, оказывается более эффективной на практике, чем типичный кодированный рукой SQL. Это приводит к неболтливым взаимодействиям DB, где Вы получаете все свои данные связанной таблицы в едином запросе. И это имеет очень хорошую поддержку оптимистической блокировки (обеспечение исключений DBConcurrency). Набор данных также отслеживает вставки, модификации и удаления к Вашим данным, таким образом, Вы не имеете к.

Наборы данных со строгим контролем типов также предлагают простую навигацию данным связанной таблицы.

Хорошая ссылка на DataSets

Программирование Microsoft® ADO.NET 2.0 Core Reference David Sceppa

Издатель: паб Microsoft Press дата: 17 мая 2006 ISBN-10 печати: ISBN-13 печати 0-7356-2206-X: 978-0-7356-2206-7 страниц: 800

+tom

Я посмотрел бы на преимущества объектов данных по сравнению с DataTables (необычная библиотека ORM не действительно необходима, хотя они могут быть хорошими):

• Концептуально чистый. Вы вынуждены применить понятия OO к своим данным. Легче понять, что "это - Человек" по сравнению с "Человеком, которого я хочу, находится где-нибудь в этой таблице".
• Осуществляет разделение проблем. Заманчиво прикрепить данные контекста UI к DataTable - для одного UI, я получаю Человека с основным адресом в той же записи, для другого я получаю Человека с кредитной информацией в той же записи. Когда я работаю с моделью, я хочу, чтобы та модель была последовательна везде, где я использую ее.

• Преобразуйте данные только однажды. В Уплотняющих таблицу данных приложениях я видел, существует многое из рассеянного на всем протяжении:

  если (строка ["седло"] == DBNull. Значение || строка. IsNullOrEmpty (строка ["седло"] как строка))...

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

• Легче к модульному тесту. При ссылке на поле в объекте данных, который не существует, Вы получаете ошибку времени компиляции. При ссылке на поле в DataTable, который не существует, Вы получаете ошибку времени выполнения.

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

Похожие страницы: Как убедить моих коллег не использовать наборы данных для развития предпринимательства (.NET 2.0 +).

Я раньше просто использовал datareader для чтения полей на мое использование объекта GetString, GetInt и т.д., но я шел дальше теперь к намного большему количеству OO и тестируемого подхода с помощью Шлюза для возврата таблицы данных из запроса, это затем передается в Класс обслуживания, который анализирует таблицу на объект.

Мне никогда действительно понравились инструменты ORM, они были всегда громоздкими и трудными поддержать, но у меня не было шанса играть с LINQ все же, таким образом, мое мнение может измениться.

Я нахожу, что могу разработать меньше кода и протестировать мой код лучше с помощью ORM, чем Наборы данных/Таблицы данных. Я в настоящее время использую LINQ-SQL и переношусь, тонкий слой вокруг разработчика сгенерировал код через частичные классы как мой ORM. Тонкий слой в основном позволяет мне добавлять некоторые основанные на роли полномочия и увеличивает тестируемость кода путем рефакторинга к интерфейсам и использования внедрения зависимости для определения контекста данных (тот способ, которым я могу копировать его для других тестов).

Я сделал и - пишут мой собственный ORM вокруг DS/DT, DS/DT со строгим контролем типов, и т.д. и переключились на LINQ, и не возвращаюсь. Я могу в конечном счете переместиться во что-то как NHibernate, Платформа Объекта или что-то еще, но на данный момент мои предложения решения LINQ в значительной степени все мне нужно, и намного более просто, чем мои старые решения.

Я использовал DataSets в первые дни .NET, затем начал использовать типизированные DataSets, со временем обнаружил, что объем памяти, оставленный DataSets очень высоки, и не имело смысла использовать неуправляемые объекты для любых простых задач.
Отсюда пришел к выводу, что DTO / POCO - лучший выбор, и начали использовать NHibernate и iBatis.
Мои средние (или ниже среднего) разработчики считали их сложными и трудными в использовании (без каламбура).
Итак, я создал самодельный ORM XmlDataMapper , который было намного проще использовать, чем существующие сложные ORM.

Для интеграции XmlDataMapper все, что вам нужно сделать, это 4 маленьких шага

1. Создать бизнес-объект / DTO для таблиц
2. Создать XML-файл с информацией о сопоставлении между таблицей и DTO.
3. Укажите DTO и XML-файл в конфигурации.
4. Просто вызовите DTOConverter.Convert (dataReader) и другие подобные методы, чтобы преобразовать запись базы данных в DTO / Business Entity