SWRда, возможно иду не тем путем, в общем излагаю как все есть:

у меня есть главное окно MainWindow.xaml, изначально я решил вынести всю общую стилизацию окна в словарь ресурсов в файле WindowStyle.xaml, в MainWindow.xaml я прописал



все работает, затем я создал дочернее окно DClass.xaml, которое также должно иметь тот же стиль, что и у главного, поэтому я так же прописал для него:




но столкнулся с проблемой, так как компоненты, которые я добавил на главное окно прописаны в том же файле в стиле WindowStyle, следовательно они будут наследоваться и в дочернее окно, я решил прописывать отдельно для каждого окна один и тот же стиль в файлах MainWindow и DClass.xaml:




правильно ли это? ведь тогда будет дублирование кода, а я бы хотел его избежать.

вот то же самое и с методами перетаскивания окна, они находятся в классе WindowStyle.cs и оба окна их должны использовать, поэтому по идее нужно унаследовать эти методы в класс дочернего окна DClass

вот в общем, не знаю понятно ли я описал
Что за методы перетаскивания окна?

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

Для главного окна создание этого главного окна, создание для него модели представления и присвое контекста данных может идти в классе App. А для дочернего - в команде, которая вызывает это дочернее окно.

Вообще, посмотрите пример достаточно простого приложения, созданного по шаблону MVVM. Там же можно исходный код скачать. Там есть прямо то, что я сказал - создание главного окна в классе App. В том приложении не создаётся дочерних окон, зато создаются дочерние вкладки в одном и том же окне. Но суть от этого не меняется - вы создаёте модель представления, создаёте представление, привязываете контекст данных представления к модели представления и вызываете это представление на показ. А что из себя представляет представление (извиняюсь за тавтологию) - окно, вкладку или ещё что-то - неважно.

Если вам нужно расшарить логику (команды, методы) между окнами, то в MVVM это значит, что вам нужно расшарить эту логику между моделями представления этих окон. Тогда, вы создаёте базовый класс для модели представления окна и помещаете туда эту логику, общую для нужных вам окон - всё как в наследовании с обычными классами.

Ну и плюс есть всякие заморочки с модальными окнами. Если фанатично следовать заветам MVVM, то там нельзя просто так из модели представления вызывать новые представления. Нужно написать сервис (просто класс), который это будет делать, и в модели представления вызывать методы этого сервиса, которые будут создавать новые представления (показывать модальное окно, например).

А если не фанатично (маленькое приложение, например), то можно вызывать новые модальные окна прямо из модели представления главного окна.

По поводу сервисов для модальных окон - http://www.codeproject.com/Articles/70223/Using-a-Service-Locator-to-Work-with-MessageBoxes
Вообще, чем дальше в лес, тем больше дров. Если упороться следованию заветам MVVM, то придётся столкнуться со всякими сервис-локаторами и прочей фигнёй, а это либо написание своих велосипедов, либо нужно разбираться и выбрать фреймворк, который предоставит вам всякие уже готовые сервис-локаторы. Ну и это не конец, конечно - правильное MVVM-преложение настолько обвязано всякими паттерн-фреймворками, что надо месяцок точно потратить, чтобы только со всем этим ознакомиться. Поэтому, если вам неохота во всём этом разбираться, просто вызывайте новое окно из команды модели представления дочернего окна. Это идёт против MVVM и разделения ответственностей (ведь теперь модель представления знает о представлении), но иногда можно на это наплевать.

Roman MejtesDoomplay998Что за методы перетаскивания окна?
Window.Move()
А зачем в дотнете их в коде делать? Не устраивает, как мышой таскается?

Сон Веры ПавловныDoomplay998По поводу сервисов для модальных окон - http://www.codeproject.com/Articles/70223/Using-a-Service-Locator-to-Work-with-MessageBoxes
Вообще в приличном обществе за использование сервис-локатора бьют по рукам и отправляют копать траншеи, поскольку он является очень вредным антипаттерном.
А как тогда в MVVM модальные окна делать?

"Проблема с Х в том, что одни его неправильно используют, а другие пишут статьи, почему Х - зло."

https://habrahabr.ru/company/pvs-studio/blog/311998/
и ещё куча подобных статей, в которых вместо "Х" можно подставить вообще любую вещь в мире.

Кухонные ножи - зло. Ими можно не только порезаться, но и, что самое страшное, ими совершается подавляющее большинство бытовых убийств. Их нужно запретить и изъять у населения.

Сон Веры ПавловныDoomplay998Кухонные ножи - зло. Ими можно не только порезаться, но и, что самое страшное, ими совершается подавляющее большинство бытовых убийств. Их нужно запретить и изъять у населения.
Неккорректная аналогия. Вы приводите пример того, как что-то может быть использовано не по назначению, скрывая контекст того, что у чего-то вообще не может быть назначения.
Ну а теперь по пунктам и аргументированно опровергните, что:
1) SL вносит неясность в контракт класса;
2) SL делает неопределенной сложность класса;
3) SL нарушает SOLID;
4) SL нарушает инкапсуляцию.
Обоснования на все четыре тезиса есть выше по ссылкам.
Возможно, автору темы просто не нужно строгое соблюдение всех этих принципов. Тогда сервис-локатор подойдёт?

Я вообще, как я говорил, прямо из кода команды (из вью-модели) вызываю дочерние окна. Или вообще из code behind. Потому что мне просто не нужно делать как-то принципиальнее и более мудрёно.