Где лучше в MVVM реализовать дополнительную логику?

	Комментарий модератора
	Тема создана разделением темы Привязка DP-свойства UserControl к вложенному элементу

Сообщение от Элд Хасп проблема безопасности, когда свойство Result может быть перезадано по месту использования DPCalculatorUC, осталось.

так оно (заданный Result) ведь всегда может быть перезадано? или я ошибаюсь... переназначить свойство - это же не удалить/создать объект заново...

мне почему-то кажется, что это не проблема, а как раз и задумано было, чтобы можно было переназначать свойства в зависимости от нужного (например, цвет текста при value>1000, условно говоря) - вот и вынесли это DP в отдельный класс... а за пример реализации и использования в XAML - спасибо!..

? только в каких случаях это DP подключают обычно?.. как по мне, так Styles и Templates и даже Converters - нормальные внутренние (для объекта) свойства, дальше которых уже и придумать нечего (с практической точки зрения) чтобы захотеть подключать из-вне класса ещё и DP за гранью всего, что можно задать и в объекте...

0

Сообщение от Andrey-MSK То бишь DbContext не пробрасывается в DI

да его вообще пробрасывать никуда не надо - ведь он не Thread-safe, поэтому всегда лучше его в using(context){..}

Сообщение от Andrey-MSK а работает только в методах репозитория

- понятно, значит там же и SaveChanges() для заброса изменений в хранилище... или сложнее: периодически по timing'у фиксить изменения (освобождая кэш)... но EF (или др ORM) начинает внедряться с DA (тоже упускалла этот момент - проясняется)

the consumer doesn’t need to know anything about what happens behind the scenes, i.e. whether the DAL uses EF, another ORM or manually creating connections and commands to execute queries against a data source.

0

Сообщение от Andrey-MSK А в WEB сервис вызывается по Transient и работает до закрытия соединения

Чисто технически там можно влепить и не Transient. Я к тому что отличий внутренней логики десктопа и веба не то что бы много: как напишешь, так и будет работать (внезапно).

Добавлено через 2 минуты

Сообщение от JeyCi да его вообще пробрасывать никуда не надо

DI не только про объекты. Пробрасывать можно и фабрику/провайдер, которые будут тебе выдавать нужный объект.

0

Сообщение от Wolfdp Чисто технически там можно влепить и не Transient.

Ну обычно делают Transient либо Scope. Но оба эти варианта уничтожают объекты после использования. Чтобы EF запускали в Singleton без using я не слышал... Тогда никакой памяти не хватит...

0

JeyCi, а вам точно ORM нужна? Это, как бы, вещь не обязательная для работы с базой...

0

Сообщение от Andrey-MSK Ну обычно делают Transient либо Scope

Который можно завмыкать и передать в Singleton.

Я вёл не в сторону "а давайте на веб-сервисе повторим как на десктопе", а скорее наоборот: для десктопа не делать долгоживущих объектов. Ну или отрубать кеш в местах где он явно не нужен.

0

Сообщение от Usaga а вам точно ORM нужна? Это, как бы, вещь не обязательная для работы с базой...

вроде для code-first - удобная... - схему всех Entities и Relations лучше (!) видно, чем вчитываться в сами SQL-запросы... `dotnet ef migrations add`- могут понадобиться - структура и классы иногда меняются... - DML для sqlite, менее актуален, чем DDL (а его можно и через sqlCommands)... да и migrations для sqlite, говорят, вроде не сделать... и с Lazy-Loading по ключам, вроде не отрабатывает, - где-то встречалось... (но sqlite или LocalDB - ещё думаю)...

• The SQLite provider does not support schemas and Sequences. • The SQLite database engine does not support the following schema operations that are supported by the majority of other relational databases.

но EDMX - для database-first approach - (пробовать) формировать из dotnet пока не получается (NET5.0 даже установить dotnet ef пока не получается, попробую ещё)... но не думаю, что будет удобно без VS (только dotnet)... в любом случае dotnet tool install --global dotnet-ef для управления миграциями и др задач EF - для sqlite не пригодится (если это правда, что там не сделать), но думаю если всё-таки предпочту LocalDB - то не помешает и EF. для code-first подхода (он как-то попроще, чем database-first или model-first).. имхо

а SaveChanges(); после валидации, вообще, по-моему, "must-have", чем просто швырять insert'ы в бд - не надо открывать клиенту доступ в бд... (только в рамках его компетенций)

LINQ to Entities можно расширять на c# (или предварительный отбор), чем всё загружать в sql...

DbSet, DbQuery и DbContext в EF - очень удобны, т.к. наследуют IQueryable - и хорошо подтягиваются из дб в WPF (как ObservableCollection из локальных объектов), и не надо winform.control.Items.Refresh(), как в WinForm... мы ведь о binding'ах говорим

-- конечно нужна нормальная ORM! в общем CRUD и миграции удобнее с ORM... а code-first проще, чем иное

0

JeyCi, из этой портянки текста не очень ясно, какую проблему ты решаешь взяв ORM...

0

DbExtensions
Этот класс определяет несколько полезных статических методов, с помощью которых можно настроить запросы, например, отключить кэширование для запросов

Usaga - и вас лично отключить, чтобы не тыкали там, где ты сам никто...

0

JeyCi, хорошо

0

там, действительно, какой-то странный Update...

Сообщение от Элд Хасп Я показал пример выше. Три Интерфейса общего применения: IReadRepository<T>, IRepository<T>, IUnitOfWork. И один интерфейс уже специфичный для предметной области: ICreditUnitOfWork. В примере же из GitHub. Один общий интерфейс: IRepository<T> И два специфичных: ICreditApplicationRepository, IUnitOfWork.

всё-таки, наверно, зависит от ситуации насколько понимаю, репозитарий может иметь свой dbContext, под один dbContext можно сделать 1 репозитарий для несложных проектов, там вроде tutorial, а не реал.проект... хотя,конечно, можно делать репозитарии и под каждую сущность...

if you want some specific operation for some specific entities. Then, you need to create a specific repository with the required operations.

- всё зависит от Single Responsibility Principle видения разработчика конкретного проекта, полагаю... (и Interface segregation и Liskov Principle - для выделения единицы [с её методами и свойствами], которая может подвергнуться изменению в жизни проекта, и какие свойства и методы вводить, а какие реализовывать только в этой сущности, а какие ещё и расширять)

но в моём случае пока будет - 1 connection- значит одного репозитария достаточно (чтобы убрать зависимость DAL от Модели) - на случай если потом расширять до MVC... а с EF так уже UnitOfWork в ней есть, да и DbContext она задаёт (тут зависимость от конкретной бд только если в OnConfiguration делать - но он ведь именно для этого и только там и только 1 раз делается, а дальше D.I. куда надо)... а в DAL, насколько помню - простые DTO пока что... (хотя с EF они не нужны, наверно и Репозитарий не нужен, - он entities сам может подхватить из ДБ -- просто add package Mirosoft.EntityFrameworkCore у меня что-то из dotnet не тянется под net5.0 пока, может файл проекта какой не такой - экспериментирую с TargetFrameworks)
Disadvantages of Repository Pattern in C#:

• Complexity: Implementing the Repository Pattern can introduce some complexity into your codebase, especially if you have a small and straightforward application. It may be overkill for simple projects. • Performance Overhead: Inefficient use of the pattern (like retrieving full datasets for a few fields) can lead to performance bottlenecks. • Learning Curve: Developers new to the Repository Pattern may need time to understand and properly implement it, which can slow down development initially. • Limited Flexibility: Generic repository patterns can limit the ability to create complex queries, leading to either under-fetching (N+1 problems) or over-fetching data. • Over-Abstraction: Sometimes, the pattern can lead to over-abstraction, where the data access layer is so abstracted that it becomes difficult to optimize specific queries or utilize certain database features.

вот кстати многие-ко-многим в EF мне нравится (можно разрулить прямо на клиенте, независимо от хранилища), да и SaveChangesAsync() не будет замораживать Main, вероятно (уже хорошо)... или какую другую Task уже можно исполнять...

When Not to Use Unit of Work in C#?

• Simple CRUD Operations: For simple applications with basic CRUD (Create, Read, Update, Delete) operations, implementing UoW might be overkill and add unnecessary complexity. • Small Applications or Microservices: In small-scale applications or microservices where transactions are simple and less frequent, the overhead of implementing UoW may not be justified. • Performance Overhead: In certain high-performance or low-latency scenarios, the overhead of managing UoW might outweigh its benefits.

в общем, если EF не поставится, ваш вариант UnitOfWork то, что надо от ADO.NET (там по линку, наверно, просто ADO.NET не использовалась для tutorial'a)... но SQL'и в Linq переводить без полноценного dbContext с ключами (который даёт EF), наверно, бессмысленно... на всё придётся писать wrappers ... хотя их и так придётся писать (другие) для каждого Layer как минимум (или, как советовалось, - создавать разные сборки)...

=========
вообще, с EF, наверно, действительно, будет неприятно - 2 раза прописывать Repository... но по др. никак... да и миграции в sqlite не нужны... значит IGenericRepository пока хватит, чтобы соблюдать Open-Closed principle... если потом на MVC...

p.s.:
касательно EF, вероятно EF больше подходит для MVC (и то для БД или, может, хранилища и выполнения приложений на облаке Azure, а для Web др DataAccessLayer, наверно, должен быть)... а MVVM (как разновидность MVC) паттерн для WPF
================ внедрять вроде и без Microsoft.Extensions не сложно, а если пока однопоточный connection к бд, то и IoC не нужен мне пока, полагаю...
Простой D.I.:
p.p.s. всё-таки EF создаёт зависимость DomainLayer от DataAccessLayer, а её надо бы развернуть - т.е. DomainLayer чтобы был независимым (чтобы WPF UI быстро переделать в Web UI)... но в принципе EntityFrameworkCore уже разработан для разных основных провайдеров - в NET.Core см. IServiceProvider для внедрения нужного IServiceCollection с помощью IoC-контейнера, а вот для вывода в web/html - он, наверно, всё-таки не подходит... просто др UI - значит подходит - в NET.Core (в отличие от NET.Framework)

в общем выходим с MVVM на более широкий смысл MVC... там и кОнтролы будут другие (не для VM) и многопоточность может появиться с race condition... для др. ветки... просто back-end пока ещё немного аморфный у меня (for generic case), поэтому и front-end у меня тоже такой же

0

Сообщение от JeyCi а вот для вывода в web/html

С какого боку EF принимает участие в формировании UI?

Без обид, но прочитал всю портянку и нифига не понял...

1

Сообщение от Andrey-MSK С какого боку EF принимает участие в формировании UI?

1

0

Сообщение от Элд Хасп Тему нужно давно разделить. Возможно даже не на 2

0) Помимо темы, озвученной в названии ветки, были затронуты вопросы:
1) Dependency Injection в NET.Core для MVVM ( Middleware injection [как разновидность D.I.] или MiddleLayer) - на примере Update
2) Расширяемая архитектура проекта (чтобы переехать с WPF на Web быстро) - на примере возможностей расширения до MVC
3) При смене БД куда деть EntityFramework (создающий зависимость Model от DbContext)

- последовательность, может, и не совсем соблюдена по ветке - т.к. ввиду того, что я не профи в архитектурных вопросах - вопросы возникали спонтанно и в контексте многоплановости конкретных задач... да и ответы были хаотичны (кто что подумал), но часто полезны для общего вопроса:
1) MVVM - правильное разделение на слои с соблюдением Open-Closed Principle из S.O.L.I.D. для быстрого внедрения доп. логики

Стоит разделять ветку или не стоит - не знаю - т.к. всё связано со всем здесь (и не всё отвечено) для полной завершённой картины о возможностях наращивать функционал проекта - но для деталей переезжать на др. ветку однозначно стоит

0

Сообщение от JeyCi Dependency Injection в NET.Core для MVVM (Middleware injection или MiddleLayer)

В WPF MVVM нет Middleware. Это из Web ASP.NET Core MVC

Сообщение от JeyCi Расширяемая архитектура проекта (чтобы переехать с WPF на Web быстро)

По всей теме сложилось впечатление, что вы наоборот делаете - едете из Web в WPF

Сообщение от JeyCi При смене БД куда деть EntityFramework (создающий зависимость Model от DbContext)

Работать через интерфейс - тогда потребителю будет абсолютно фиолетово что там по капотом, какая СУБД и какая технология доступа к ней.

1

Сообщение от Andrey-MSK едете из Web в WPF

уже приехала - в БД... на С++ в своё время... - думаю, вставлять ли тот проект Unmanaged Code'ом во взаимодействие с бд сюда (или вообще переделать на c#) или оставить как есть и делать др. проект для визуализации инфо из бд... задача обычная: взять инфо из сети, закинуть в бд для истории, посмотреть нужные данные из бд по мере необходимости... т.е. из Web - в БД - в WPF... (и может потом закинуть Хранилище на облако) - (и может потом закинуть анализ инфо из этого хранилища в Web )

0

JeyCi, "Всё смешалось в доме Облонских" (с)

0

- то что в названии ветки, потом:
- handling Exceptions in WPF
- тут получили посыл к многопоточности (где нужен MVC)

Сообщение от Элд Хасп Простейшая задача встречающаяся "на каждом углу". Есть некая коллекция отражающая многопользовательскую БД.

- потом всё ещё рассматривали команды (в асинхронном коде) ... правда потом AsyncRelayCommand вспомнили из CommunityToolkit фреймворка...
- посмотрели Synchronization Context
- асинхронно CanExecuteChanged , но в потоке диспетчера окна - на примере 2х кнопок... - предостерижение о всё той же асинхронности... и ранее:

Сообщение от Элд Хасп - хотите обязательно CanExecuteChanged по Event'у, иначе Disabled... - Пусть не по эвенту. Любое асинхронное (по отношению к GUI) изменение модели, для корректного состояния кнопки с командой, требует поднятия CanExcuteChanged команды после этого изменения.

- пример тех.задания на авторизацию - смена View по вводу Login, вспомнили про разделение привилегий... authorizationException как Property...
- отсюда начали перестраивать мозг с WinForms(MVP) на WPF (MVVM), и далее опять на многопоточную архитектуру MVC...
- а отсюда - то что в (1) из #114 -- уже обсуждение расширяемой архитектуры

чтобы не перечитывать всё - вот примерно такое СОДЕРЖАНИЕ ВЕТКИ было (многоплановое и немного mixed-up) -- для расширения C++ кода возможностями С#

1

JeyCi, Andrey-MSK, wizard41, просмотрел тему.
Там такая каша.
Разделять надо не просто по сообщениям, а сами сообщения тоже.
Слишком много волокиты.

Эту тему я закрою.

JeyCi, для следующих вопросов создавайте новые темы.

2