Почему призма использования?
Несколько причин
Заголовочные файлы
Каждая единица компиляции требуют, чтобы были сотни или даже тысячи заголовков (1) загружены и (2) скомпилированы. Каждые из них обычно должны быть перекомпилированы для каждой единицы компиляции, потому что препроцессор гарантирует, что результат компиляции заголовка мог бы варьироваться между каждой единицей компиляции. (Макрос может быть определен в одной единице компиляции, которая изменяет контент заголовка).
Это, вероятно главная причина, поскольку она требует, чтобы огромные объемы кода были скомпилированы для каждой единицы компиляции, и дополнительно, каждый заголовок должен быть скомпилирован многократно (однажды для каждой единицы компиляции, которая включает ее).
Соединение
Когда-то скомпилированный, все объектные файлы должны быть соединены. Это - в основном монолитный процесс, который не может очень хорошо быть параллелизирован и должен обработать Ваш весь проект.
Парсинг
синтаксис является чрезвычайно сложным для парсинга, зависит в большой степени от контекста и является очень твердым снять неоднозначность. Это занимает много времени.
Шаблоны
В C#, List<T> единственный тип, который компилируется, неважно, сколько инстанцирований Списка Вы имеете в своей программе. В C++, vector<int> абсолютно отдельный тип от vector<float>, и каждый должен будет быть скомпилирован отдельно.
Добавляют к этому, что шаблоны составляют полный полный по Тьюрингу "подъязык", который должен интерпретировать компилятор, и это может стать смехотворно сложным. Даже относительно простой шаблонный код метапрограммирования может определить рекурсивные шаблоны, которые создают десятки и десятки шаблонных инстанцирований. Шаблоны могут также привести к чрезвычайно составным типам, со смехотворно длинными именами, добавив большую дополнительную работу компоновщику. (Это должно сравнить много имен символа, и если эти имена могут превратиться во многие тысячи символов, которые могут стать довольно дорогими).
И конечно, они усиливают проблемы с заголовочными файлами, потому что шаблоны обычно должны определяться в заголовках, что означает, что намного больше кода должно быть проанализировано и скомпилировано для каждой единицы компиляции. В простом коде C заголовок обычно только содержит предописания, но очень мало фактического кода. В C++ почти всему коду весьма свойственно находиться в заголовочных файлах.
Оптимизация
C++ допускает некоторую очень поразительную оптимизацию. C# или Java не позволяют классам быть полностью устраненными (они должны быть там в отражательных целях), но даже простая шаблонная метапрограмма C++ может легко генерировать десятки или сотни классов, все из которых встраиваются и устраняются снова в фазе оптимизации.
, Кроме того, программа C++ должна быть полностью оптимизирована компилятором. Программа C# может полагаться на JIT-компилятор для выполнения дополнительной оптимизации во время загрузки, C++ не получает никакие подобные "вторые возможности". То, что генерирует компилятор, столь оптимизировано, как он собирается добраться.
Машина
C++ компилируется в машинный код, который может быть несколько более сложным, чем Java байт-кода или использование.NET (особенно в случае x86). (Это упоминается из полноты только потому, что она была упомянута в комментариях и таком. На практике этот шаг вряд ли возьмет больше, чем крошечная часть общего времени компиляции).
Заключение
большинство этих факторов совместно используется кодом C, который на самом деле компилирует справедливо эффективно. Шаг парсинга намного более сложен в C++ и может поднять значительно больше времени, но основной преступник является, вероятно, шаблонами. Они полезны, и делают C++ намного более мощным языком, но они также плохо сказываются с точки зрения скорости компиляции.
4 ответа
Prism offers a bit more than the region system. Not exhaustively:
- the View-Model command system
- Event aggregator, for decoupled event handling (with a lot of options built-in, such as GUI thread calling, weak references etc)
- a standard way to load modules, if you need that kind of flexibility
The region system is also more than simply a "content presenter wrapper". It can be used to "push" (put a view into a region) or "pull" (let modules declare which region they populate). It also support much more than simple contentpresenter regions (ItemsControl based regions for example) and is extensible through region adapters.
Last, but maybe not least, when you adopt Prism's formalism, you bet on a common "language" (and almost framework, even if the prism team doesn't call it like that) that outsiders may already know, instead of re-inventing your own which would require someone to learn a whole new set of things. It can be a good thing for a long-lived project (provided Prism does not die too young obviously).
Если вы знаете, что такое Composite Application Block, в основном это то же самое.
If you are already compositing your pages in a way where the various sub-components of the page are independent then PRISM (or the forerunner Composite UI Application Block) isn't really buying you much other than a recognized "standard" way of doing compositing that is documented.
The benefit of compositing is that each of the components in the user interface can be developed individually and then tied together late in the production cycle. This means that you have generated components that can be used in multiple places easily and your communication between components is happening via a well defined interface rather than the typical "throw the components on the page and talk to the state" approach.
So, if what you are doing now works, I probably would continue with it. If what you have is underdeveloped, consider something like PRISM if you have a lot of developers working on the parts and pieces and another developer or group pulling these pieces together into full blown user interfaces for the user. My experience is with the Composite UI Application Block and it brought a lot to the table in large projects, but the promised simplifications sound good for even a modest sized project.
Я бы выделил здесь разделение на части разрабатываемых модулей. Это позволяет отдельным более мелким командам разрабатывать части приложения, а затем объединять их в конце.
Я также хотел бы сказать, что MVVM определенно подходит для этого, но CAG также рекомендует использовать внедрение зависимостей. для ваших ViewModels, что делает их более тестируемыми, чем в противном случае. Конечно, вы можете использовать внедрение зависимостей без CAG, но приятно иметь это формальное поощрение.