Посмотрел на Prism такое ощущение что просто назвали сущности по другому
Window — Shell
ContentControl — Region
В итоге все равно приходится всю разметку делать как обычно и ContentControl заполнять данными через DataTemplate который идентифицируется типом вьюмодели.
Activate/Deactivate — чем это отличается от управления Visibility через bool и VisibilityConverter ?

Система компонентов и загрузки зависимостей по мере необходимости — а надо оно ? в .NET разве нет штатного механизма подгрузки модулей по мере использования ?

IoC — взято просто Unity.

Что я не увидел в Prism ? Или это такое название для стандартной разработки на WPF　?

Здравствуйте, okon, Вы писали:



O>Посмотрел на Prism такое ощущение что просто назвали сущности по другому
O>Window — Shell
O>ContentControl — Region
O>В итоге все равно приходится всю разметку делать как обычно и ContentControl заполнять данными через DataTemplate который идентифицируется типом вьюмодели.
O>Activate/Deactivate — чем это отличается от управления Visibility через bool и VisibilityConverter ?

O>Система компонентов и загрузки зависимостей по мере необходимости — а надо оно ? в .NET разве нет штатного механизма подгрузки модулей по мере использования ?

O>IoC — взято просто Unity.

O>Что я не увидел в Prism ? Или это такое название для стандартной разработки на WPF　?

Исходники же открыты, можно посмотреть что там есть.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, okon, Вы писали:



O>>Посмотрел на Prism такое ощущение что просто назвали сущности по другому
O>>Window — Shell
O>>ContentControl — Region
O>>В итоге все равно приходится всю разметку делать как обычно и ContentControl заполнять данными через DataTemplate который идентифицируется типом вьюмодели.
O>>Activate/Deactivate — чем это отличается от управления Visibility через bool и VisibilityConverter ?

O>>Система компонентов и загрузки зависимостей по мере необходимости — а надо оно ? в .NET разве нет штатного механизма подгрузки модулей по мере использования ?

O>>IoC — взято просто Unity.

O>>Что я не увидел в Prism ? Или это такое название для стандартной разработки на WPF　?

K>Исходники же открыты, можно посмотреть что там есть.

Cобственно выше я и описал кратко состав исходников из основного, вот и интересно что я не доглядел важного.

Здравствуйте, okon, Вы писали:

O>Здравствуйте, karbofos42, Вы писали:

K>>Здравствуйте, okon, Вы писали:



O>>>Посмотрел на Prism такое ощущение что просто назвали сущности по другому
O>>>Window — Shell
O>>>ContentControl — Region
O>>>В итоге все равно приходится всю разметку делать как обычно и ContentControl заполнять данными через DataTemplate который идентифицируется типом вьюмодели.
O>>>Activate/Deactivate — чем это отличается от управления Visibility через bool и VisibilityConverter ?

O>>>Система компонентов и загрузки зависимостей по мере необходимости — а надо оно ? в .NET разве нет штатного механизма подгрузки модулей по мере использования ?

O>>>IoC — взято просто Unity.

O>>>Что я не увидел в Prism ? Или это такое название для стандартной разработки на WPF　?

K>>Исходники же открыты, можно посмотреть что там есть.

O>Cобственно выше я и описал кратко состав исходников из основного, вот и интересно что я не доглядел важного.

Реализуй с MVVM подходом на голом WPF и с Prism, станет понятно что это и зачем.

го, вот и интересно что я не доглядел важного.

K>Реализуй с MVVM подходом на голом WPF и с Prism, станет понятно что это и зачем.

Так вот у меня и получилось что подход с MVVM на голом и с Prism ничем не отличается кроме названия.
Можешь привести кейс на основании которого ты говоришь что будет видно разницу ?

Здравствуйте, okon, Вы писали:

O>го, вот и интересно что я не доглядел важного.

K>>Реализуй с MVVM подходом на голом WPF и с Prism, станет понятно что это и зачем.

O>Так вот у меня и получилось что подход с MVVM на голом и с Prism ничем не отличается кроме названия.
O>Можешь привести кейс на основании которого ты говоришь что будет видно разницу ?

В главном окне кнопка и текстблок. При нажатии на кнопку нужно показать окно с текстом из текстблока.

Здравствуйте, okon, Вы писали:


Я из призмы тырил некоторые некоторые вещи до того как аналоги попадали в основную ветку. Unity, кстати, в частности. И вообще, она и рекламировалась как набор идей для воровства. Что касается WPF, то есть проблема компилируемости, что сильно усложняет в рантайм управление модульностью. В какой-то степени в призм эту задачу попытались решить.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>го, вот и интересно что я не доглядел важного.

K>>>Реализуй с MVVM подходом на голом WPF и с Prism, станет понятно что это и зачем.

O>>Так вот у меня и получилось что подход с MVVM на голом и с Prism ничем не отличается кроме названия.
O>>Можешь привести кейс на основании которого ты говоришь что будет видно разницу ?

K>В главном окне кнопка и текстблок. При нажатии на кнопку нужно показать окно с текстом из текстблока.

Пример из призмы
https://prismlibrary.com/docs/wpf/dialog-service.html



Пример на WPF c MVVM без сторонних библиотек

<Application.Resources>
   <DataTemplate DataType="{x:Type MainWindowViewModel}” >
      <TextBox Text={Binding InputText}" />
      <Button Command="{Binding ShowDialogCommand}" />
   </DataTemplate>

   <DataTemplate DataType="{x:Type ChildWindowViewModel} >
     <TextBlock Text={Binding Text} /> 
    </DataTemplate>
</Application.Resources>

public interface IDialogService 
{
   void ShowDialog(object dataContext);
}

public class DialogService : IDialogService
{
   public DialogService(IContainer container)
   {
     ....
   }
       
   void ShowDialog(object dataContext)
   {
      var window = container.Resolve<Window>(dataContext);
      window.ShowDialog();
   }
}

public class ParentWindowViewModel  : ....
{
   public MyViewModel(IDialogService dialogService, IContainter container) 
   {
       .... 
       ShowDialogCommand = new DelegateCommand(OnShowDialog);
   }

   private inputText;
   public string InputText { get => inputText set => Set(ref inputText, value); }

   public ICommand ShowDialogCommand {get;}

   public OnShowDialog(object parameter)
   { 
      var childWindowViewModel = container.Resolve<ChildWindowViewModel>(InputText);
      dialogService.ShowWindow(childWindowViewModel);
   }   
}

Пример на WPF c MVVM c библиотекой WpfToolkit

<Application.Resources>
   <DataTemplate DataType="{x:Type MainWindowViewModel} >
      <TextBox Text={Binding InputText}" />
      <Button Command="{Binding ShowDialogCommand}" />

      <wpfToolkit:ChildWindow  Opened="{Binding IsChildDialogOpened}" >
            <TextBlock Text={Binding InputText} /> 
      </wpfToolkit:ChildWindow>

   </DataTemplate>
</Application.Resources>


public class ParentWindowViewModel  : ....
{
   public MyViewModel() 
   {
       .... 
       ShowDialogCommand = new DelegateCommand(OnShowDialog);
   }

   private string inputText;
   public string InputText { get => inputText set => Set(ref inputText, value); }

   private bool isChildDialogOpened;
   public bool IsChildDialogOpened{ get => isChildDialogOpenedset => Set(ref isChildDialogOpened, value); }


   public ICommand ShowDialogCommand {get;}

   public OnShowDialog(object parameter)
   { 
      IsChildDialogOpened= true;
   }   
}

И в итоге опять спрашивается нафига еще одна сущность в виде библиотеки с именем Prism, может там это как-то красивее решается чем в примере из документации (https://prismlibrary.com/docs/wpf/dialog-service.html) ?

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, okon, Вы писали:


GZ>Я из призмы тырил некоторые некоторые вещи до того как аналоги попадали в основную ветку. Unity, кстати, в частности. И вообще, она и рекламировалась как набор идей для воровства. Что касается WPF, то есть проблема компилируемости, что сильно усложняет в рантайм управление модульностью. В какой-то степени в призм эту задачу попытались решить.

А что за проблема компилируемости ?

Здравствуйте, okon, Вы писали:

O>И в итоге опять спрашивается нафига еще одна сущность в виде библиотеки с именем Prism, может там это как-то красивее решается чем в примере из документации (https://prismlibrary.com/docs/wpf/dialog-service.html) ?

Ну, если хочется самому создавать всякие BindableBase, DialogService, прикручивать IoC и т.п. то Prism не нужен.
Логично, что всё, что есть в Prism, можно сделать самому
Можно и WPF не брать, а сделать свой, еще и кроссплатформенный.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>И в итоге опять спрашивается нафига еще одна сущность в виде библиотеки с именем Prism, может там это как-то красивее решается чем в примере из документации (https://prismlibrary.com/docs/wpf/dialog-service.html) ?

K>Ну, если хочется самому создавать всякие BindableBase, DialogService, прикручивать IoC и т.п. то Prism не нужен.
K>Логично, что всё, что есть в Prism, можно сделать самому
Не я понимаю вещи на которые тратится например час два и более.

K>Можно и WPF не брать, а сделать свой, еще и кроссплатформенный.
Это ты передергиваешь, все таки написать WPF это большие трудозатраты — не сравнимые с объявлением интерфейса с парой методов.

В призме нету DialogService готового, только интерфейс. А реализовывать также самому надо.
В том же примере погляди, я бы еще понял если они там запилили что-то типа ChildWindow как в wpfToolkit , это хотя бы упрощает решение.

Вот все надо реализоывать вручную чтобы показать диалог. Чем это решение упрощает жизнь ?

ublic class NotificationDialogViewModel : BindableBase, IDialogAware
{
    private DelegateCommand<string> _closeDialogCommand;
    public DelegateCommand<string> CloseDialogCommand =>
        _closeDialogCommand ?? (_closeDialogCommand = new DelegateCommand<string>(CloseDialog));

    private string _message;
    public string Message
    {
        get { return _message; }
        set { SetProperty(ref _message, value); }
    }

    private string _title = "Notification";
    public string Title
    {
        get { return _title; }
        set { SetProperty(ref _title, value); }
    }

    public event Action<IDialogResult> RequestClose;

    protected virtual void CloseDialog(string parameter)
    {
        ButtonResult result = ButtonResult.None;

        if (parameter?.ToLower() == "true")
            result = ButtonResult.OK;
        else if (parameter?.ToLower() == "false")
            result = ButtonResult.Cancel;

        RaiseRequestClose(new DialogResult(result));
    }

    public virtual void RaiseRequestClose(IDialogResult dialogResult)
    {
        RequestClose?.Invoke(dialogResult);
    }

    public virtual bool CanCloseDialog()
    {
        return true;
    }

    public virtual void OnDialogClosed()
    {

    }

    public virtual void OnDialogOpened(IDialogParameters parameters)
    {
        Message = parameters.GetValue<string>("message");
    }
}

Т.е. в данном случае намного и дешевле объявить свой интерфейс чем тащить дополнительный модуль отдельную сборку ради этого.
А BindableBase есть во всех MVVM библиотеках, IoC также подключается независимо от Prism, даже когда это не интерфейсный проект.

Здравствуйте, okon, Вы писали:

O>Здравствуйте, karbofos42, Вы писали:

K>>Здравствуйте, okon, Вы писали:

K>>Можно и WPF не брать, а сделать свой, еще и кроссплатформенный.
O>Это ты передергиваешь, все таки написать WPF это большие трудозатраты — не сравнимые с объявлением интерфейса с парой методов.

Ну, у каждого свои границы велосипедостроения.

O>В призме нету DialogService готового, только интерфейс. А реализовывать также самому надо.

А это что?
https://github.com/PrismLibrary/Prism/blob/master/Source/Wpf/Prism.Wpf/Services/Dialogs/DialogService.cs

O>В том же примере погляди, я бы еще понял если они там запилили что-то типа ChildWindow как в wpfToolkit , это хотя бы упрощает решение.

O>Вот все надо реализоывать вручную чтобы показать диалог. Чем это решение упрощает жизнь ?

В том же примере три строчки для показа простого диалога:
1) Регистрация диалога:

containerRegistry.RegisterDialog<NotificationDialog, NotificationDialogViewModel>();

2) Получение сервиса через IoC в конструкторе VM:

_dialogService = dialogService;

3) Вызов диалога:

dialogService.ShowDialog("NotificationDialog", ...); // Вырезал передачу параметров в диалог

O>Т.е. в данном случае намного и дешевле объявить свой интерфейс чем тащить дополнительный модуль отдельную сборку ради этого.
O>А BindableBase есть во всех MVVM библиотеках, IoC также подключается независимо от Prism, даже когда это не интерфейсный проект.

Ну, можно попробовать почитать доки по Prism или статьи со сравнением разных MVVM фреймворков или забить и велосипедить/использовать что-то другое.
Очень странная позиция — не разобрался, никто не навязывает и не заставляет использовать, но осуждаю.

Здравствуйте, karbofos42, Вы писали:

K>Здравствуйте, okon, Вы писали:

O>>Здравствуйте, karbofos42, Вы писали:

K>>>Здравствуйте, okon, Вы писали:

K>>>Можно и WPF не брать, а сделать свой, еще и кроссплатформенный.
O>>Это ты передергиваешь, все таки написать WPF это большие трудозатраты — не сравнимые с объявлением интерфейса с парой методов.
K>Ну, у каждого свои границы велосипедостроения.

Да но врятли ты захочешь пользоваться библиотекой где будет объявлен только пара тебе нужных методов — проще их написать самому а не делать зоопарк из разных библиотек.

O>>В призме нету DialogService готового, только интерфейс. А реализовывать также самому надо.

K>А это что?
K>https://github.com/PrismLibrary/Prism/blob/master/Source/Wpf/Prism.Wpf/Services/Dialogs/DialogService.cs

Ага спасибо, не увидел.

O>>Т.е. в данном случае намного и дешевле объявить свой интерфейс чем тащить дополнительный модуль отдельную сборку ради этого.
O>>А BindableBase есть во всех MVVM библиотеках, IoC также подключается независимо от Prism, даже когда это не интерфейсный проект.

K>Ну, можно попробовать почитать доки по Prism или статьи со сравнением разных MVVM фреймворков или забить и велосипедить/использовать что-то другое.
K>Очень странная позиция — не разобрался, никто не навязывает и не заставляет использовать, но осуждаю.

Так я и смотрел доки статьи — и по большей части вижу что это мне не облегчает жизнь, а только создает дополнительные сущности.
Стало интересно что все таки там маст хэв.
Осуждаю в тех рамках в которых разобрался, поэтому и задавал вопрос что я не разглядел интересного.

Здравствуйте, okon, Вы писали:

O>Здравствуйте, karbofos42, Вы писали:

K>>Здравствуйте, okon, Вы писали:

O>>>Здравствуйте, karbofos42, Вы писали:

K>>>>Здравствуйте, okon, Вы писали:

K>>>>Можно и WPF не брать, а сделать свой, еще и кроссплатформенный.
O>>>Это ты передергиваешь, все таки написать WPF это большие трудозатраты — не сравнимые с объявлением интерфейса с парой методов.
K>>Ну, у каждого свои границы велосипедостроения.

O>Да но врятли ты захочешь пользоваться библиотекой где будет объявлен только пара тебе нужных методов — проще их написать самому а не делать зоопарк из разных библиотек.

Проще и надёжнее взять готовое и проверенное тысячами людей. Даже в MVVMLight есть свой смысл, хотя там уж именно, что пара классов.

O>Так я и смотрел доки статьи — и по большей части вижу что это мне не облегчает жизнь, а только создает дополнительные сущности.
O>Стало интересно что все таки там маст хэв.
O>Осуждаю в тех рамках в которых разобрался, поэтому и задавал вопрос что я не разглядел интересного.

На главной странице документации на буржуйском написано кратко что за библиотека и зачем она нужна.
Библиотеки нужно выбирать под свои задачи и требования, а не из-за того, что это название где-то мелькает периодически.
Если комфортно разрабатывать без сторонних библиотек, то и не нужно ничего тащить в проект.

O>>Да но врятли ты захочешь пользоваться библиотекой где будет объявлен только пара тебе нужных методов — проще их написать самому а не делать зоопарк из разных библиотек.
K>Проще и надёжнее взять готовое и проверенное тысячами людей. Даже в MVVMLight есть свой смысл, хотя там уж именно, что пара классов.
K>Если комфортно разрабатывать без сторонних библиотек, то и не нужно ничего тащить в проект.

Об этом и речь, мне и интересен мотив разработчиков которые активно используют Prism в проектах, понимающие обширные возможности в том числе базового WPF,
понимая что в Prism именно нового и полезного, а что есть велосипед.
Пока получается что цена дополнительного модуля выше, особенно если в проекте уже есть любая MVVM библиотека.

Здравствуйте, okon, Вы писали:

K>>Если комфортно разрабатывать без сторонних библиотек, то и не нужно ничего тащить в проект.

O>Об этом и речь, мне и интересен мотив разработчиков которые активно используют Prism в проектах, понимающие обширные возможности в том числе базового WPF,
O>понимая что в Prism именно нового и полезного, а что есть велосипед.
O>Пока получается что цена дополнительного модуля выше, особенно если в проекте уже есть любая MVVM библиотека.

У меня в недавнем прошлом проекте был этот Prism.
Абсолютно не понимаю, на кой чёрт его туда притащили, да еще и сверху еще одну свою библиотеку навернули. Адъ и израиль в общем.
Мотив, на мой взгляд — RDD, во времена, когда Prism притащили, "Pattern & Practices" был хайповым, вместе с Enterprise Library, да упокоится этот монстр с миром.
Единственное что имело там смысл, imho — Unity, но она вообще как-то сбоку, да и сейчас полно аналогов.

Здравствуйте, okon, Вы писали:

O>>>Да но врятли ты захочешь пользоваться библиотекой где будет объявлен только пара тебе нужных методов — проще их написать самому а не делать зоопарк из разных библиотек.
K>>Проще и надёжнее взять готовое и проверенное тысячами людей. Даже в MVVMLight есть свой смысл, хотя там уж именно, что пара классов.
K>>Если комфортно разрабатывать без сторонних библиотек, то и не нужно ничего тащить в проект.

O>Об этом и речь, мне и интересен мотив разработчиков которые активно используют Prism в проектах, понимающие обширные возможности в том числе базового WPF,
O>понимая что в Prism именно нового и полезного, а что есть велосипед.
O>Пока получается что цена дополнительного модуля выше, особенно если в проекте уже есть любая MVVM библиотека.

Ну, Prism из коробки даёт какую-никакую навигацию, базовый набор для MVVM, внедрение и возможность миграции между разными IoC, модульность.
Если какая-то MVVM библиотека уже есть, то наверно не нужен Prism или же наоборот нужно переходить на Prism и выкидывать другую библиотеку.
Если брать какой-нибудь MVVMLight, то его для любой самой минимальной программы придётся допиливать, т.к. он совсем уж лайт.
На Prism вполне базовые сценарии отработают без допиливаний. Навигацию на регионах набросал быстренько и в продакшен.
Кому-то нравится этот фреймворк — берёт его, кто-то его еще и допиливает, а кто-то другой берёт или делает свой.
Это же всё сплошной субъективизм

K>Ну, Prism из коробки даёт какую-никакую навигацию, базовый набор для MVVM, внедрение и возможность миграции между разными IoC, модульность.

Насчет миграции — никто не обеспечит миграцию одной библиотеки на другую кроме самого разработчика. Если ты будешь писать код на базе интерфейсов которые в призм — у тебя будет зависимость по всему коду от призмы.
И заменить призму на клизму будет сложно без переделки всего кода.

K>Если какая-то MVVM библиотека уже есть, то наверно не нужен Prism или же наоборот нужно переходить на Prism и выкидывать другую библиотеку.

K>Если брать какой-нибудь MVVMLight, то его для любой самой минимальной программы придётся допиливать, т.к. он совсем уж лайт.
А что там пришлось допиливать для минимальной программы ?

K>На Prism вполне базовые сценарии отработают без допиливаний. Навигацию на регионах набросал быстренько и в продакшен.
Навигация вообще выглядит как профанация, она в WPF как бы и так есть по умолчанию — хочешь удобно переключаться между вьюшками — меняй Content или DataContext и все.

K>Кому-то нравится этот фреймворк — берёт его, кто-то его еще и допиливает, а кто-то другой берёт или делает свой.
K>Это же всё сплошной субъективизм

Здравствуйте, okon, Вы писали:

K>>Если брать какой-нибудь MVVMLight, то его для любой самой минимальной программы придётся допиливать, т.к. он совсем уж лайт.
O>А что там пришлось допиливать для минимальной программы ?

Навигация через Messemger — такое себе удовольствие

K>>На Prism вполне базовые сценарии отработают без допиливаний. Навигацию на регионах набросал быстренько и в продакшен.
O>Навигация вообще выглядит как профанация, она в WPF как бы и так есть по умолчанию — хочешь удобно переключаться между вьюшками — меняй Content или DataContext и все.

Повторюсь:

K>>Это же всё сплошной субъективизм