Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
В любом случае это не поможет в части удалённых записей и изменивших критерий отбора (ни в датасете ни в EF). Тогда как тупой полный перезапрос - вполне себе поможет (только для винформс это надо обделать хитро - лучше всего просто пересоздать контекст и перепровязать BS к "свежему" списку).
------------------ WBR, Igor |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
что-то у меня совсем крышу сносит напиши pls несколько строк примера |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Дискуссия разбилась на 2 составляющие)))
Кодирование и архитектура))) Об архитектуре. Вполне возможно, что в конкретно твоем случае, твой подход верен. Ответь, ск. времени выполняется выборка с нужным фильтром? Об изменении. Опять смешаны 2 разных момента. Обновление 1й записи в коллекции (повторяю, ничего сложного, и думаю быстро) (вопрос - зачем, отбрасываем) Об этом именно веду речь. И обновление по TimeStamp. Никаких вариантов тут не видно. Простых. Потому как ты редактируешь, список произвольного размера. Не, написать можно, нет сомнений. В голове крутится функция для этого. Но Игорь упомянул, что даже автоматом все сработает. Но и про коллизии он рассказал. И думаю, это только то что на поверхности, в реале, гораздо больше трудностей будет... Просто, можно предположить, что это главная задача проекта? В общем, важен ответ на вопрос ск. идет выборка) И еще. Я не знаток винформс, но лучше работать с данными, как будто ты в вебе. Все равно, тренд весь в ту сторону. ------------------ |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
Вчера вечером понял, что уже нарываюсь на крутые заморочки с кэшем, решил делать все с нуля по описанию микрософта
описание с сайта микрософта Creating a Model docs.microsoft.com [attachment 29854 2018-08-1008_14_48-CreatingaModel-EF6_MicrosoftDocs.png] Пишет Игорь
ладно, в данном случае я поверю Игорю Дохожу до создания модели в проекте project->new item->Data->ADO.NET Entity Data Model получаю выбор [attachment 29856 2018-08-1008_33_09-EntityDataModelWizard.png] Помня слова Игоря, что подход Code First не для этого, выбираю другой доступный вариант для существующей базы (первая иконка) Пара секунд и получаю в проекте PortModel.edmx т.е. получил модель, на которую "уже давно забили" простой вопрос - как лучше сгенерировать модель для проекта? Исправлено 1 раз(а). Последнее : AlexSSS, 10.08.18 08:53 |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
все, про timestamp забыли
на больших списках - 1-3сек когда я обновляю на экране весь список - это не критично. но если это время я получаю, когда мне надо обновить только одну запись - это неприемлимо Исправлено 1 раз(а). Последнее : AlexSSS, 10.08.18 09:09 |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
По первому вопросу. Ты все правильно делаешь.
Забудь))) Все работает. Получаешь edmх. Вот про него можно забыть))) Но можно в нем связи подсмотреть, вряд ли тебя сейчас это интересует. Ты правильно описал свои действия, и модель сгенерирована. Открой что получилось, там как бы папки, и внутри, и контекст, и все классы. Все окейно) Мы победили!!))))
Ок. Ну давай рассмотрим весь процесс. У тебя в гриде, но давай как будто это отдельная форма, а потом втащим это в грид. Открыл форму редактирования, получил в нее запись с сервера. Отредактировал, сохранил на сервер, и коли все успешно, обновил этими данными, по id свой список (1 запись) Я спецом не думаю о каких то коллизиях. Это потом))) Точно та же логика, получается в гриде. Просто логику эту, опиши отдельно, а потом вставишь, куда надо. Это я так думаю, так бы я решал. ------------------ |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Если хочется иметь чуть более "умный" источник данных - позволяющий хотя бы сортировать себя без перезапросов или тех же вручную прописываемых .OrderBy() для уже извлечённой коллекции (это вариант, но потребует вручную писать код для каждой нужной сортировки - хоть это и всего 1 строка, но утомительно же ж), то надо обернуть List<Person> в коллекцию с реализацией IBindingListView, свою писать, конечно, муторно, потому можно взять к примеру Equin.ApplicationFramework.BindingListView<T> - через нугет пакеты подключается без проблем. Это позволит в датагридвью настроить "автоматическую" сортировку при кликах по хедеру (а в соответствующем событии ColumnHeaderMouseClick можно и для Programmatic сортируемой колонки несложный код прописать). Никак. Модель не генерируется, а пишется. Ибо CODEfirst Т.е. тупо и незамысловато
------------------ WBR, Igor Исправлено 1 раз(а). Последнее : Igor Korolyov, 10.08.18 10:16 |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
Понятно. Я так и думал, но меня что смутило db = new MyDBContext() - по аналогии с датасетом - это новый экземпляр датасета на одной форме у меня может быть до десятка DataSource основной bsPersons.DataSource = db.Persons.Where(лямбда с условиями).ToList(); и датасорсы для подчиненных таблиц, для персонала, это, напр, могут быть bsCompany bsDepartment bsСitizenship и т.д. сейчас для всех DataSource на форме я использую один db = new MyDBContext() не будет ли проблем на других DataSource после того, как я пересоздам db для какого-то одного? и не будет ли регулярный db = new MyDBContext() засерать память старыми экземплярами? |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
у меня уже написаны и отработаны несколько классов, которые работают со стандартным BindingSource. Та же сортировка или фильтрация строк по условию без перезагрузки данных. Думаю, придется чуть их изменить для работы с Entity вместо Dataset, но это проще, чем писать новые классы на EF, с которыми мне еще разбираться и разбираться. не знаю насколько полно стандартный BindingSource интегрирован с EF, но, напр, BindingSource bs = oTabControl.oBindingSource; bs.EndEdit(); вызывало сохранение данных на сервере ;) без отдельного вызова SaveChanges кстати, что уже оценил при этом - на сервер шли обновления только тех полей, которые изменились (у меня при отладке на SQL Server запущен профайлер, где я вижу, какие команды приходят из программы) |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
так похоже, у тебя все решилось.? ------------------ |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
это другое - entity сохраняет изменения на сервере, посылая код только с измененными полями т.е. направление entity->ms sql server |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
$#$&^$ сейчас стал проверять - хоть ошибок и не выдается, ни сортировка ни фильтрация не работают |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Аспид Автор Сообщений: 3475 Откуда: Москва Дата регистрации: 01.04.2005 |
Почему же? Он отослал изменения, которые у тебя есть, зачем тебе именно эту запись назад? Она и так у тебя уже есть. ------------------ |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
ВладимирС Сообщений: 1693 Дата регистрации: 03.11.2005 |
БОЛЬШОЕ спасибо за разъяснения... Проанализирую... |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Да, именно так. По хорошему лучше их тоже перезапросить и перепровязать их BS, т.к. при работе попытка записать в свойства объекта "нового" контекста ссылку на объект "старого" ничем хорошим не закончится. Да, в принципе их (вспомогательные сущности и их коллекции) можно перепривязать к новому контексту. Или же не пересоздавать контекст, а просто выкинуть оттуда все объекты перед запросом "свежего состояния коллекции" - конечно это чуть больше кода потребует. Нет, не будет. Правда я забыл строчку db?.Dispose() перед прописыванием нового - этот объект следует явно "закрывать" (иначе он закроется только когда у сборщика мусора дойдёт до него дело). В более других сценариях использования его вообще в using (var db = new ...) прописывают, и он автоматом закрывается при выходе из этого блока. Это предсказуемо DataView через который ты и "смотришь" на данные в DataTable реализует интерфейс IBindingListView в котором и есть эти старинные фильтр и сортировка. Чистый List<T>, конечно же, не реализует эти методы. Можно либо самому заморочиться, благо при помощи linq не составляет проблемы ни отсортировать готовую коллекцию, ни "отфильтровать" из неё подмножество (хотя фильтр всё же лучше спускать пониже - к коду извлечения из БД, т.е. к DbSet<T>.Where()). Ну или вышеупомянутая готовая реализация - оборачиваешь обычный List<T> в неё и старинные, убогонькие методы с bs.Sort = "Name, Age DESC, Salary" начинают работать... ------------------ WBR, Igor |
Re: c# winforms унифицировать обращение к TableAdapter | |
---|---|
AlexSSS Сообщений: 6113 Откуда: Tallinn, Estonia Дата регистрации: 19.09.2005 |
Цитата: конечно, предсказуемо. Если знать, как это устроено. ;) |
© 2000-2024 Fox Club  |