Добрый день,
У меня задача переписать/доработать существующее приложение, написанное на Access + Excel.
Новое приложение:
Серверная часть – SQL Server 2008R2(уже почти закончена),
Клиентская часть – C#, Winforms, .Net не выше 4.0 (в процессе разработки).
Я сейчас продумываю организацию работы с данными клиентского приложения. Буду рад услышать комментарии, советы.
В этом приложении Entity Framework использоваться не будет, соответственно работать нужно будет или через нетипизированные или через типизированные Dataset-ы.
Первым стал вопрос использовать типизированный Dataset или нет. Сеппа в своей книге, подробно описав каждый из них, предлагает выбор делать каждому, но сам он склоняется к обычным, нетипизированным Dataset-ам. Его аргументы: быстрее(если обращаться к полям не по имени и не по индексу, а как к объекту), нет глюков(он описывает какие именно), бОльшая свобода.
Как ни странно я остановился именно на типизированном. Почему так.
Во-первых, пришлось задуматься о конфликтах обновления. В Access при обновлении записи в форме, в случае конфликта записи, выдается сообщение, что пока вы правили запись, другой пользователь внес в нее свои изменения. Пользователю предлагается выбор: скопировать запись в буфер и оценить различия, отказаться от своих изменений или сохранить свою версию записи. Мастер создания типизированного Dataset берет на себя организацию проверки на конфликты. Если не ошибаюсь CommadBuilder делает тоже самое, генерируя логику обновления, а именно условие отбора строится таким образом, когда исходное значение каждого поля обновляемой записи сравнивается со значением соотв.поля в базе данных на сервере. Есть поле timestamp или нет его, а такой подход всегда предотвратит конфликт записей.
В общем, без системы решения конфликтов остаться я не хочу, свою систему с псевдо блокированием записей делать тоже не хочу, поэтому решил, что предлагаемый механизм меня устроит.
Но тут оказалось, что буквально первый же источник данных, который я предложил тестовому гриду, причем также созданный с помощью мастера, оказался не в состоянии создать команды на удаление/обновление/добавление. CommandBuilder также не смог их создать. Там запрос по нескольким таблицам, очевидно, не по возможностям мастера и CommandBuilder.
Писать аналогичные запросы руками, чтобы потом подсовывать их соответствующим командам, не то, что утомительно, это просто было бы невыносимо.
Обошелся так. Мастер создает типизированный Dataset, и простую логику обновления/удаления/добавления по таблице, а я вручную добавляю в таблицу дополнительные нужные поля, используемые запросом на выборку, и задаю тот самый «сложный» запрос на выборку по нескольким таблицам. В общем, в таком режиме проектировать не утомительно.
Во-вторых. Типизированный Dataset позволяет мне расширять код , созданный мастером, используя partial классы. В Access при вводе данных интерфейс каждой формы (события формы/контролов), должен обеспечивать различные проверки. Недостаток в том, что код может дублироваться от формы к форме. Мне показалось, что в C# программе я смогу вынести все подобные проверки в partial классы соответствующих типизированных DataTable, написать их один раз. Эдакие триггеры. Тем самым сняв нагрузку с интерфейса. Я так думал…
Но чем больше занимаюсь темой, тем больше разочарование. Надеюсь, я просто еще не представляю, как это можно реализовать лучшим образом и мне подскажут.
Что хотелось бы. Все проверки вынести в partial классы типизированных Dataset. Проверки разместить на события объекта DataTable. Событий вроде как достаточно:
https://msdn.microsoft.com/en-us/library/system.data.datatable_events(v=vs.110).aspx
Но, что получается. Допустим перед сохранением записи на событие RowChanging выполнены проверки, выданы сообщения и нужно отменить сохранение и продолжить редактирование. Отменить событие можно только возбудив исключение. Но при этом все внесенные изменения будут потеряны, запись вернется в исходное состояние.
Вольно или невольно, но я тяготею к привычному мне способу работы, а именно, когда запись в гриде изменена и производится попытка перехода на другую запись, вызывая сохранение записи, в нашем случае это событие RowChanging. Так вот, если проверка не прошла и событие нужно отменить, то пользователь, получив сообщения должен остаться на той же записи грида, а сама запись должна остаться в том же самом состоянии, в которое ее привел пользователь.
Но в моем случае, когда пользователь переходит на другую запись грида, вызывая тем самым событие DataTable RowChanging, отмена события(возбуждение исключения) приводит к том, что запись возвращается в исходное состояние, в котором была до редактирования, а текущей станет та запись, на которую собственно был осуществлен переход.
А вот если бы я повесил все проверки на события грида, то очевидно, я бы добился желаемого мной способа взаимодействия. Но именно этого(ориентированность на события интерфейса) мне и хотелось бы избежать.
В общем я в замешательстве.
Как быть? Не получится обойтись только событиями Dataset?
Кстати, а ведь если вести работу не через интерфейс, а программно, то в этом случае я ж ведь никак не смогу воспрепятствовать событию RowChanging. Если возбужу исключение, то потеряю все внесенные данные. Мысль о том, что изменения можно запомнить, а потом снова внести в туже строку, гоню от себя подальше . Так можно утонуть в этой событийной зависимости.
Можно, конечно, запретить делать правки в гридах, а все изменения вносить только через «карточки», где взять контроль над событиями в свои руки, но делать так мне не хочется.
Хотелось бы услышать советы, комментарии, мнения.
Спасибо.
