Коллеги, подскажите, правильно ли организован проект.
Есть несколько форм, которые редактируют таблицы одной единственной БД. Формы немодальные, постоянно доступны все. VStudio размещает на каждой форме DataSet с xxTableAdapter, в результате, каждая форма содержит копию данных (пусть не полную, но таблицы тесно связаны, поэтому приходится прогружать большинство таблиц).
Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
Еще одной проблемой текущей организации является синхронизация данных между формами. Так как у каждой свой DataSet, то синхронизация осуществляется через БД (у активной Update, у всех остальных Fill), что тоже довольно ресурсоёмко.
Подскажите, пожалуйста. Опыта .Net не много, страшно рефакторить, хорошо не подумав.
Здравствуйте,
Во-первых, напрашивается использование какого-нибудь ORMа.
Он будет работать как глобальное хранилище записей таблиц в программе (хотя смысл ORM гораздо шире).
Работа напрямую с датасетами постепенно уходит в прошлое.
Здравствуйте, Павел А.Ануфриков, Вы писали:
ПАА>Коллеги, подскажите, правильно ли организован проект.
ПАА>Есть несколько форм, которые редактируют таблицы одной единственной БД. Формы немодальные, постоянно доступны все. VStudio размещает на каждой форме DataSet с xxTableAdapter, в результате, каждая форма содержит копию данных (пусть не полную, но таблицы тесно связаны, поэтому приходится прогружать большинство таблиц).
ПАА>Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
Можно легко огрести в будущем если база будет использоваться из нескольких процессов.
Здравствуйте, chocho, Вы писали:
ПАА>>Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
C>Можно легко огрести в будущем если база будет использоваться из нескольких процессов.
А как вы представляете работу с одним датасетом из нескольких процессов?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, chocho, Вы писали:
ПАА>>>Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
C>>Можно легко огрести в будущем если база будет использоваться из нескольких процессов.
L>А как вы представляете работу с одним датасетом из нескольких процессов?
Я её не представляю, поэтому и не советую его исползовать, чтобы потом не расстраиваться.
Здравствуйте, chocho, Вы писали:
ПАА>>Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
C>Можно легко огрести в будущем если база будет использоваться из нескольких процессов.
Расшифруйте, пожалуйста, мысль, я тоже её не понял. Процессов м.б. несколько, но у каждого будет свой датасет в глобальных данных.
Здравствуйте, victor_kr, Вы писали:
_>Лучше уходить от DataSet-ов. Почитайте об ORM, например, NHibernate или Entity Framework. В интернете много примеров и пошаговых инструкций.
Спасибо. А я правильно понял, что технология не приемлема для БД на MS Access?
По Entity Framework не могу найти ссылок, но думаю, что тоже можно настроить подключение.
По моему мнению, в любом случае, даже если бы не было возможности использовать ORM библиотеку (специфические режимы работы с базой данных, специфическая база данных), лучше работать со своими классами, чем с DataSet. ORM всего лишь помогает, так как предлагает готовую модель работы с базой данных. Можно реализовать свою модель. Если база данных простая, то получится быстрее чем с ORM.
Здравствуйте, Павел А.Ануфриков, Вы писали:
ПАА>Есть ли смысл переделывать проект, чтобы был один DataSet в глобальном хранище, и все формы обращались к нему? Огребу ли я, если пойду таким путем?
Мерять логику инструментами неверный подход ведущий в постоянный нетрадиционный секс. Для того чтобы тебе понять нужен или не нужен тебе кэш, нужно сначало посчитать действия пользователя, как должны реагировать остальные формы на то или иное действие. И только потом можно сказать подходит или не подходит тот, или иной инструмент. Постоить кэш легко. Но в многих случаях, обеспечивать его когерентность — мудизъм. Тут ошибка может стоить дорого.
Здравствуйте, Павел А.Ануфриков, Вы писали:
ПАА>Расшифруйте, пожалуйста, мысль, я тоже её не понял. Процессов м.б. несколько, но у каждого будет свой датасет в глобальных данных.
Процессов несколько, а БД на MS Access — одна?
Вот тут вы точно можете огрести.