Сколько объектов DataTable я должен использовать в своем приложении C#?
Я опытный программист в устаревшем (но объектно-ориентированном) средстве разработки и перехожу на C# /. Net. Я пишу небольшое однопользовательское приложение с использованием SQL-сервера CE 3.5. Я прочитал концептуальный DataSet и связанный с ним документ, и мой код работает.
Теперь я хочу убедиться, что делаю это «правильно», получить отзывы опытных программистов .Net / SQL Server, которых вы не получите, прочитав документ.
Я заметил, что у меня есть такой код в нескольких местах:
var myTableDataTable = new MyDataSet.MyTableDataTable();
myTableTableAdapter.Fill(MyTableDataTable);
... // other code
В однопользовательском приложении вы бы обычно просто делали это один раз при запуске приложения, создавали экземпляр объекта DataTable для каждой таблицы, а затем сохраняли ссылку на него, чтобы вы когда-либо просто использовали этот единственный объект, который уже заполнен данными? Таким образом, вы будете читать данные из базы данных только один раз, а не несколько раз. Или накладные расходы на это настолько малы, что это просто не имеет значения (плюс может быть контрпродуктивным для больших таблиц)?
Вы имеете в виду, что я могу использовать LINQ в качестве поставщика данных для всего моего приложения?
Вы можете использовать LINQ для захвата данных и привязки к результатам вместо использования DataSets и TableAdapaters. ИМХО, это гораздо более плавный рабочий процесс.
Спасибо, Уилл, я это проверяю. Я предполагаю, что это также направление, в котором идет этот тип кода.
Ответы 4
Для CE это, вероятно, не проблема. Если вы продвигали это приложение тысячам пользователей, и все они использовали централизованную базу данных, вы можете потратить некоторое время на оптимизацию. В однопользовательской БД, такой как CE, я бы не стал беспокоиться об этом, если у вас нет данных, которые говорят о необходимости оптимизации. Преждевременная оптимизация и т. д.
Способ различать между двумя главными вещами 1. Будет ли доступ к данным постоянно 2. Много ли данных
Если вы постоянно используете данные в таблицах, загрузите их при первом использовании. Если вы используете данные лишь изредка, заполняйте таблицу, когда они вам нужны, а затем отбрасывайте ее.
Например, если у вас 10 экранов графического интерфейса пользователя и вы используете myTableDataTable только на одном из них, читайте его только на этом экране.
Выбор действительно не зависит от самого C#. Это сводится к балансу между:
- Как часто вы используете данные в своем коде?
- Изменяются ли данные когда-либо (и вас это волнует)?
- Какова относительная (временная) стоимость повторного получения данных по сравнению со всем остальным, что делает ваш код?
- Какое значение вы придаете спектакль по сравнению с усилия / время разработчика (для этого конкретного приложения)?
Как правило: для производственных приложений, где данные меняются нечасто, я бы, вероятно, создал DataTable один раз, а затем придерживался ссылки, как вы упомянули. Я бы также подумал о том, чтобы поместить данные в типизированную коллекцию / список / словарь вместо общего класса DataTable, если не что иное, потому что легче позволить компилятору уловить мои опечатки.
Для простой утилиты, которую вы запускаете для себя, которая «запускается, делает свое дело и заканчивается», это, вероятно, не стоит усилий.
Вы спрашиваете о Windows CE. В этом случае я, скорее всего, выполню запрос только один раз и сохраню результаты. Мобильные ОС имеют дополнительные ограничения в батареях и пространстве, которых нет у программного обеспечения для настольных компьютеров. По сути, мобильная ОС делает пункт 4 гораздо более важным.
Каждый раз, когда вы добавляете еще один поисковый вызов из SQL, вы чаще вызываете внешние библиотеки, что означает, что вы, вероятно, работаете дольше, чаще выделяете и высвобождаете больше памяти (что добавляет фрагментацию) и, возможно, вызываете повторное чтение базы данных из Флэш-память. Скорее всего, гораздо лучше сохранить данные, когда они у вас есть, если вы можете (см. пункт 2).
Ответить на этот вопрос легче, если вы думаете о наборах данных как о «сеансе» данных. Вы заполняете наборы данных; вы работаете с ними; а затем вы возвращаете данные или отбрасываете их, когда закончите. Поэтому вам нужно задавать такие вопросы:
- Насколько актуальными должны быть данные? Вам всегда нужно иметь самую последнюю версию, или база данных будет меняться не так часто?
- Для чего вы используете данные? Если вы просто используете его для отчетов, вы можете легко заполнить набор данных, запустить свой отчет, затем выбросить набор данных и в следующий раз просто создать новый. В любом случае это даст вам больше текущих данных.
- О каком количестве данных мы говорим? Вы сказали, что работаете с относительно небольшим набором данных, поэтому не будет серьезного воздействия на память, если вы загрузите все это в память и удержите там навсегда.
Поскольку вы говорите, что это однопользовательское приложение без большого количества данных, я думаю, что вы можете безопасно загружать все вначале, использовать его в своих наборах данных, а затем обновлять по завершении.
Главное, о чем вам нужно позаботиться в этом сценарии: что, если приложение завершает работу ненормально из-за сбоя, отключения электроэнергии и т. д.? Потеряет ли пользователь всю свою работу? Но, как правило, наборы данных чрезвычайно легко сериализовать, поэтому вы можете довольно легко реализовать процедуру «периодически сохранять», чтобы сериализовать содержимое набора данных на диск, чтобы пользователь не потерял много работы.
Если вы переходите на .NET, я бы посоветовал пропустить ADO и взглянуть на Linq.