|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
|||||||||||||
Разделение функционала между слоями MVVM на примере создания простого WPF приложения с БД10.02.2024, 00:12. Показов 8822. Ответов 182
Метки нет (Все метки)
Тема создана разделением темы Вывод на печать изображения MVVM
Кликните здесь для просмотра всего текста
0
|
|||||||||||||
| 10.02.2024, 00:12 | |
|
Ответы с готовыми решениями:
182
ASP.NET MVC - разделение функционала между различными view
WPF нюансы создания проводника и мелочи по MVVM |
|
|
||||
| 27.02.2024, 00:02 | ||||
|
Здесь, я бы сказал, вы пытаетесь сделать так: Допустим, есть проект "Чайник". В нем есть уровень воды и температура. Оба этих параметра нам нужно контролировать. Не смотря на то, что оба объекта: уровень и температура фактически являются описательными для данного проекта, вы их разносите по разным проектам. И это, с некоторой позиции нормально, т.к. эти проекты могут быть использованы, например, в кофеварке или стиральной машине. Но прямо, это разделение не привносит ясности в саму суть разделения MVVM. Т.е. связь между ними, согласно паттерну, можно осуществить и в пределах одного решения. Допустим, мы сохраняем параметры уровня и температуры в БД, через какие-то интервалы времени. Сегодня у нас база - MSSQL. Завтра мы передумали, и перешли на Postgres, а через неделю понадобилась MySQL. О-па! Куда это все совать? В Common? Нееет! Вот тут это могут быть или отдельные проекты типа Провайдеров, каждый со своим функционалом, либо же один отдельный проект со всеми ими. Фактически, возвращаемые данные и запросы к этим БД одинаковы; меняются только строки подключения.
0
|
||||
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||||
| 27.02.2024, 00:11 [ТС] | ||||
|
Добавлено через 41 секунду Так как этот класс работает напрямую с источником, то у него не получится отобрать ссылку на DataBase Добавлено через 7 минут А Common по вышеописанным примерам, описал почему не лучший для объединения. э Исходя из этого Везде где наследуется интерфейс идёт работа с данными, а данные это бд. Из этого можно задуматься зачем разделять интерфейсы и бд и тем более их реализацию готовых методов. Так как скакать придется по проектам еще больше. А пример занятный описали.
0
|
||||
|
|
|
| 27.02.2024, 00:16 | |
|
xellan24rus, работа (обязанность) БД - предоставлять данные. Через интерфейс можно VM дать понять - данные какого типа ожидать. Но VM вообще не должна знать, что эти данные выбираются из какой-то БД. Сегодня это БД, завтра json с сервера.
0
|
|
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||
| 27.02.2024, 00:17 [ТС] | ||
|
0
|
||
|
Модератор
|
||
| 27.02.2024, 00:29 | ||
|
Изменение источника в вашей реализации приводит в перекомпиляции всех вышестоящих слоёв. Вы просто этого не замечаете, так как Студия делает это автоматические. Сделайте связи через сборки, а не через проекты и вы сразу поймёте, то что я с wizard41 пытаемся вам объяснить.
0
|
||
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
|||
| 27.02.2024, 00:55 [ТС] | |||
|
К примеру сейчас у ConsoleApp идет зависимость на Repository и у главного проекта такая же зависимость. Так как Repository связан с типами DataBase и реализует нужные интерфейсы, то зависимость идёт только к типам. А на это уже нет никакого решения, если User в ConsoleApp используется, то и в главном проекте он User, если я изменю User на Users то придется лезть в оба проекта. Но так как работа с данными идёт только в одном классе, тот же метод Add, Remove, FirstOrDefault. То не состоит труда изменить бд, на json или xml. Ведь типы останутся прежними. Добавлено через 4 минуты И даже если я разделю работу с данными People и Product на разные классы, то при изменение источника мне придется лезть во все эти классы, не говоря уже о дубле кода. Но это позволит сократить ссылки на DataBase, то есть можно меньше обращаться к типам, но не мало важно что при обновлении типа можно заменить разом через поиск, а вот дубли кода придется делать вручную. Добавлено через 6 минут И даже если для работы будут разные классы с дублями кода, то ориентироваться в таком приложение сложнее. И так как эти классы будут ссылаться на проект с источником или источник, то эта зависимость всегда будет. В этом вопросе не вижу выхода какого то, которое сведет правки на минимум. Редактирование дублей кода или же замена типов, сейчас речь идёт об этом. wizard41, можете посмотреть реализацию на данный момент, я вроде бы всё подчистил лишнее.
0
|
|||
|
|
||
| 27.02.2024, 01:35 | ||
|
xellan24rus, хоть вопрос адресован Элд Хасп'у, все же вставлю свои 5 копеек:
интерфейс - это контракт, который обязаны соблюдать все, кто наследуется от него. И естественно, если что-то в нем меняется, то эти изменения необходимо отразить и в объектах-наследниках. Поэтому, желательно сразу продумывать то, что в нем будет. Если все же есть некоторые сомнения, то интерфейсы поддерживают различного рода перегрузки и реализации по умолчанию. Но на данный момент, вроде как, вопрос не о них. У тебя сейчас получается VM должна знать (знает) о каком-то репозитории, через который(!) получает еще и тип ProductData. О типе ProductData должен сообщить интерфейс, а выбрать коллекцию ProductData должна модель и передать ее VM. От куда эта коллекция взялась - VM вообще не должно волновать. Грубо говоря: ты скрыл от всех реализацию сбора данных, и никто не должен знать как она работает. Может быть она шифрованная и в объекты их преобразует твой супер-алгоритм, который ты никому не хочешь показывать. Я прихожу со своим окном (VM) и говорю - дай-ка мне свои данные из БД... И тебе придется раскрыть мне добрую половину своих моделей/типов, чтобы мое окно поняло то, что туда летит. Добавлено через 21 минуту На вскидку скажу одно: уж очень все раскидано, что, вероятно, привносит "кашу" в понимание. Там, смотрю, еще EF участвует со своими DbSet'ами. Я, однажды, уже прошел в некоторой степени "муки ада" понимания mvvm шаблона, впрочем, как и Элд Хасп, поэтому, нам, вероятно проще в голове выстроить связи "на лету". А тем, кто только начинает - лучше "прочувствовать" это все руками, не прибегая к помощи фреймворков.
1
|
||
|
Модератор
|
|||||||
| 27.02.2024, 10:11 | |||||||
|
Как написал выше wizard41: интерфейс - это контракт. Изменение контракта - естественно повлечёт изменение работы всех принявших этот контракт.Но DataBase - это не контракт, а его реализация. Например, вы захотели просто изменить название БД:
Но при сильных ссылках в других проектах - перекомпиляция сборки зависимости вынуждает перекомпилировать и все зависимые сборки. В вашем случае у VM есть сильная ссылка на эту сборку из-за типов Person и Product. А у проекта View есть сильная ссылка на сборку VM. Поэтому такое простое изменение имени БД приведёт к перекомпиляции сборок всех слоёв. А это именно то с чем призваны бороться паттерны MV*.
0
|
|||||||
|
|
|||
| 27.02.2024, 10:19 | |||
|
0
|
|||
|
Модератор
|
|
| 27.02.2024, 10:19 | |
|
xellan24rus, представьте себя себе руководителем мирового мегапроекта.
Над каждым вашим проектом работает своя отдельная команда. Каждая команда имеет свою территориальную локацию: США, Россия, Индия и т.д. Вы раздали командам контракты (интерфейсы или базовые классы), которые они должны реализовать. И после этого нужно обеспечить независимость работы команд. Не должно быть такого, что мелкие изменения внесённые одной командой приводят к необходимости вносить изменение (перекомпилировать) их сборки (проекты).
0
|
|
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||||||||||||||||
| 27.02.2024, 10:21 [ТС] | ||||||||||||||||
|
Если я сделаю public interface ProductData: ViewModelBase, IProduct тогда ViewModelBase не будет являться интерфейсом и придется наследовать в Vm и делать повторную реализацию. Поэтому не совсем понимаю зачем дублировать код интерфейса, ведь для Vm модель данных уже реализована. Элд Хасп, пока занят был обдумывал всё. Про сильные зависимости, к примеру есть ConsoleApp. В нем есть некий код
0
|
||||||||||||||||
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||
| 27.02.2024, 10:23 [ТС] | ||
|
0
|
||
|
|
||
| 27.02.2024, 10:24 | ||
|
0
|
||
|
Модератор
|
||
| 27.02.2024, 10:28 | ||
|
Приложение - это место сборки всех его частей. Поэтому там могут быть сильные ссылки на любые сборки. Пример: получен экземпляр DataSet по сильной ссылке, потом он внедрён в экземпляр Command (Модели) по слабой ссылке, который дальше внедрён в экземпляр VM тоже по слабой ссылке, а тот внедрён по слабой ссылке в View. То есть App имеет сильный ссылки на все слои, но создание зависимостей между слоями происходит по слабым ссылкам.
0
|
||
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||
| 27.02.2024, 10:29 [ТС] | ||
|
Я так понимаю это уберет лишние зависимости. Но тем не менее для ProductData так как он реализует IProduct и используется в ObservableCollection<ProductData> ProductDataList, то есть свойство для Vm. Вот тут я не понял, зачем интерфейс для Vm то нужен.... Если под каждый чих делать интерфейс, то придется слишком сильно скакать. Ведь если делать репозиторий для Product, то команды базовые будут реализованы и в одну строчку использованы в Vm для нужной команды.
0
|
||
|
Модератор
|
||
| 27.02.2024, 10:33 | ||
|
Если там только строка подключения - это одно. А если изменения типа Хранилища, его архитектуры, то изменение строки подключения в настройках приложения не всегда хватит. В данном случае - это детали реализации Репозитория, которые по большому счёту к рассматриваемой ьтеме не имеют отношения. Важно только чтобы детали реализации Репозитория не влияли на другие слои.
0
|
||
|
364 / 296 / 55
Регистрация: 08.04.2020
Сообщений: 1,175
|
||
| 27.02.2024, 10:34 [ТС] | ||
|
0
|
||
|
Модератор
|
||
| 27.02.2024, 10:40 | ||
|
Это может быть интерфейс, может быть базовый (абстрактный класс). Но он должен быть в отдельной сборке от его реализации. Иначе не получится убрать сильные связи между слоями. Как будет время (на выходных скорее всего) - я покажу в своей ветке, как это нужно сделать. Для этого не требуется много времени - время требуется для вникания в проект, так как просто забываю что и как там. В том числе введение контрактов, вместо сильных связей, очень сильно экономит время для сторонних разработчиков необходимое для вникание в решение.
0
|
||
| 27.02.2024, 10:40 | |
|
Структура WPF приложения на MVVM
Паттерн MVVM или как писать приложения на WPF
Пример переключения между окнами WPF MVVM Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Кредитный калькулятор
Maks 05.08.2026
Решение задачи по прикладной информатике средствами 1С.
Задача:
Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .
|
У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35".
kumehtar 04.08.2026
С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .
|
Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники).
Hrethgir 04.08.2026
Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .
|
Термопринтер QR701
Argus19 03.08.2026
Термопринтер QR701
Купил два термопринтера QR701.
На сэлф-тесте написано:
Language: PC936 (GB18030).
Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .
|
|
Создание формы заимствованного документа
Maks 03.08.2026
Задача:
Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также
табличная часть со следующими реквизитами:
- Расчетный счет покупателя. . .
|
Задача предоставления скидок покупателям
Maks 03.08.2026
Задача:
В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .
|
Почему SEO не начинается с ключевых слов: что проверить до написания текстов
Neotwalker 01.08.2026
Когда владельцу сайта предлагают заняться SEO, первым шагом часто становится сбор запросов и написание текстов.
Логика кажется понятной:
1. Находим ключевые слова.
2. Добавляем их на. . .
|
Знание — сила: Доктрина интенциональности знаний, углубление в формулу
Hrethgir 01.08.2026
https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11957&stc=1&d=1785567302
Знаменитый афоризм Фрэнсиса Бэкона «Знание — сила» (Scientia potentia est) в массовой культуре принято понимать. . .
|