ООП и таблицы данных для любителей ранга

Question

Я абсолютный любитель, пишу небольшое приложение для отслеживания изменений в папках. Я предполагаю, что буду хранить информацию о каталогах для просмотра в одной таблице данных, связанной с видом сетки, когда пользователь нажимает кнопку, программа создаст FileSystemWatchers, чтобы следить за каталогами, и они отправят свои сообщения о событиях в другой источник данных связан с другим видом сетки. Где в широком широком мире ООП я должен объявлять, инициировать и манипулировать таблицами данных? Главная форма, внутри main, в классе, или я должен «сдаться» и использовать Visual Studio для автоматического создания DataSet и вставить в него две таблицы?

Answer 1

Ну лошадей на курсах. Для небольшого вспомогательного приложения вам, вероятно, будет лучше использовать стиль программирования VS "Visual / RAD". Например, перетащите таблицы и т. Д. На форму, как показано в большинстве учебных пособий.

Строго говоря, для более крупного приложения более правильным способом было бы создать отдельную сборку (.dll), которая обрабатывает доступ к данным, и вы вызываете классы в этой сборке из главной формы. Эта концепция имеет несколько терминов, но фактически вы хотите отделить свои проблемы. Другими словами, пусть пользовательский интерфейс обрабатывает взаимодействия с пользовательским интерфейсом, имеет отдельную сборку / проект / все, что обрабатывает интерактивность базы данных, и другую отдельную сборку / проект / все, что обрабатывает бизнес-логику и т. Д.

Эта последняя пара предложений может означать разные вещи для разных людей, и нет 100% правильного способа сделать вещи.

Некоторые статьи, которые могут помочь:

текст ссылки
текст ссылки
текст ссылки

Answer 2

Я согласен с KiwiBastard: вы получаете немало преимуществ от использования инструментов VS для генерации типизированного DataSet.

Это просто порождает классы. Вы все еще должны управлять экземпляром DataSet. Для очень простого приложения, где я не разделил пользовательский интерфейс и бизнес-логику на разные классы, я бы сделал это в форме. Для приложения любой сложности это часть класса бизнес-логики.

Что-то, что, вероятно, избавит вас от многих проблем: привязка данных хороша, ADO хорош, но определенные виды кода ADO (в частности, обработчики событий в DataTable) плохо работают с привязкой данных. Если вы используете BindingSources (и, действительно, так и должно быть), обычно рекомендуется приостановить привязку всякий раз, когда вы манипулируете объектами DataSet программно (например, когда вы добавляете и удаляете строки). Стоимость приостановки и возобновления привязки очень мала, и это устраняет целый класс проблем, которые чрезвычайно трудно диагностировать.