ООП и таблицы данных для любителей ранга
https://stackoverflow.com/questions/227678
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я абсолютный любитель, пишу небольшое приложение для отслеживания изменений в папках. Я предполагаю, что буду хранить информацию о каталогах для просмотра в одной таблице данных, привязанной к сетке, когда пользователь нажимает кнопку, программа создаст FileSystemWatchers, чтобы следить за каталогами, и они отправят свои сообщения о событиях в другую таблицу данных связан с другим видом сетки. Где в широком широком мире ООП я должен объявлять, инициировать и манипулировать таблицами данных? Основная форма, внутри main, в классе, или я должен "сдаться" и использовать Visual Studio для автоматического создания набора данных и вставить в него две таблицы?
Решение
Ну лошадей на курсах. Для небольшого вспомогательного приложения вам, вероятно, будет лучше использовать VS " Visual / RAD " стиль программирования. Например, перетащите таблицы и т. Д. На форму, как показано в большинстве учебных пособий.
Строго говоря, для более крупного приложения более правильным способом было бы создать отдельную сборку (.dll), которая обрабатывает доступ к данным, и вы вызываете классы в этой сборке из главной формы. Эта концепция имеет несколько терминов, но фактически вы хотите отделить свои проблемы. Другими словами, пусть пользовательский интерфейс обрабатывает взаимодействия с пользовательским интерфейсом, имеет отдельную сборку / проект / все, что обрабатывает интерактивность базы данных, и другую отдельную сборку / проект / все, что обрабатывает бизнес-логику и т. Д.
Эта последняя пара предложений может означать разные вещи для разных людей, и не существует 100% правильного способа сделать это.
Некоторые статьи, которые могут помочь:
Другие советы
Я согласен с KiwiBastard: вы получаете немало преимуществ от использования инструментов VS для генерации типизированного DataSet.
Это просто порождает классы. Вы все еще должны управлять экземпляром DataSet. Для очень простого приложения, где я не разделил пользовательский интерфейс и бизнес-логику на разные классы, я бы сделал это в форме. Для приложения любой сложности это часть класса бизнес-логики.
Что-то, что, вероятно, избавит вас от многих проблем: привязка данных хороша, ADO хорош, но определенные виды кода ADO (в частности, обработчики событий в DataTable) плохо работают с привязкой данных. Если вы используете BindingSources (и, действительно, так и должно быть), обычно рекомендуется приостановить привязку всякий раз, когда вы манипулируете объектами DataSet программно (например, когда вы добавляете и удаляете строки). Стоимость приостановки и возобновления привязки очень мала, и это устраняет целый класс проблем, которые чрезвычайно трудно диагностировать.
