Обновление данных

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

Эти вопросы в основном связаны с тем, какой вид адекватности и целостности данных нужен от слоя данных в среде с высоким уровнем параллелизма. На основе ответов на эти вопросы можно прикинуть возможную схему управления параллельной работой. После обдумывания такой схемы нужно оценить, как в точности вы будете реализовывать в слое данных обнаружение параллелизма и разрешение конфликтов. А чтобы создать такие средства работы с параллелизмом, необходимо решить, какие встроенные возможности ADO.NET будут задействованы.

После определения схем управления параллельной работой появится следующий большой вопрос: какую производительность вы хотите выжатъ из слоя данных. Хотите ли вы положиться на автоматически сгенерированные команды, которые формируются по принципу «один размер на всех”? Хотите ли вы кэшировать команды? А параметры команд? Нужно ли создать специальные команды, которые будут работать со специальными структурами таблиц и бизнес-объектов, но с риском запутывания управления всеми командами? А может, лучше использовать возможности конкретной СУБД и передавать данные на сервер в сыром виде — тогда решение будет практически не переносимым на другие СУБД, зато гораздо более эффективным?

И, наконец, нужно задать один из наиболее важных вопросов, на которые требуется ответ при проектировании слоя данных: “Для чего я проектирую этот слой данных и сколько труда я готов вложить в него?» Стоит ли разработка самого лучшего и эффективного способа хранения данных усилий на разработку однопользовательского приложения для обособленного компьютера?

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

Оказывается, как и в реальной жизни, в ADO.NET ничего не достается на халяву. Как и везде, чем больше усилий вы вложите в слой данных, тем выше будет его производительность и тем чише будут данные. Учитывая то, что на каждый из приведенных выше вопросов можно ответить множеством различных способов, хорошо бы знать все эти способы и трудоемкость каждого из них.

Знание различных методов, которыми ADO.NET позволяет заносить изменения или новые данные в базу данных, позволяет принять осознанные решения на эти три вопроса — и именно этому посвящена данная глава и следующие.

Эти две главы построены по принципу “прежде чем ходть, поползай, а прежде чем бегать, походи». Приведенные примеры начинаются с самых простых и наращивают сложность и сходство с реальной жизнью. В любом случае будут рассмотрены все за и против каждого подхода, которые позволят вам осознанно решить, годится ли вам этот подход в архитектуре вашего приложения.

Прежде чем начать наше путешествие, нужно упомянуть еще один важный момент: где начинаются существенные различия между отдельными СУБДи поставщиками данных. Представленные здесь примеры будут рабоаать на локальном экземпляре SQL Server 2005 с базой данных Test. Соответствующие SQL-сценарии можно загрузить с web-сайта издательства; однако по мере обсуждения будут указываться любые существенные различия с Oracle.

Теперь начнем с самого простого — рассмотрим, как ADO.NET обновляет данные.

Related posts:

Генерация строк подключений для конкретных поставщиков
Создание строго типизированных DataSet
Выборка данных: класс DataAdapter
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий