Выбор между MEF и MAF (система. AddIn)
Пожалуйста, примените это http: // localhost: 8000 / messages / all /? Type = workflow
удалите "из URL
, если type не является workflow просто поднять ошибку
if type == 'workflow':
print("TRUEEEEEEEEEEEEEeeeee")
queryset = ....
else:
from rest_framework.exceptions import NotFound
raise NotFound(detail="no notifications", code=404)
5 ответов
Я оценивал эти варианты и вот к выводу, к которому я пришел.
MAF - это настоящая аддонная среда. Вы можете полностью разделить свои надстройки, даже запустив их в отдельном домене приложения, чтобы в случае сбоя надстройки оно не остановило ваше приложение. Он также предоставляет очень полный способ развязать аддоны от чего-либо, кроме контракта, который вы им даете. Фактически, вы можете управлять версиями своих контрактных адаптеров, чтобы обеспечить обратную совместимость со старыми надстройками при обновлении основного приложения. Несмотря на то, что это звучит великолепно, за пересечение доменов приложений приходится платить высокую цену. Вы платите эту цену за скорость, а также за гибкость типов, которые вы можете отправлять туда и обратно.
MEF больше похож на инъекцию зависимостей с некоторыми дополнительными преимуществами, такими как обнаруживаемость и ... (здесь нет текста). Степень изоляции, которую имеет MAF, отсутствует в MEF. Это две разные структуры для двух разных вещей.
What Danielg said is good. I would add:
If you watch the videos about System.Addins, they are clearly talking about very large projects. He talks about one team managing the host application, another team managing each AddIn, and a third team managing the contract and the pipeline. Based on that, I think System.Addins is clearly for larger applications. I'm thinking applications such as ERP systems like SAP (maybe not that big, but you get the idea). If you watched those videos you can tell that the amount of work to use System.Addins is very large. It would work well if you had a lot of companies programming 3rd party add-ins for your system and you can't break any of those add-in contracts under penalty of death.
On the other hand, MEF seems to share more similarities to SharpDevelop's add-in scheme, the Eclipse plugin architecture or Mono.Addins. It's much easier to understand than System.Addins and I believe it to be a lot more flexible. The things you lose are that you don't get AppDomain isolation or strong versioning contracts out-of-the-box with MEF. MEF's strengths are that you can structure your entire application as a composition of parts, so you can ship your product in different configurations for different customers, and if the customer buys a new feature, you just drop the part for that feature into their install directory and the application sees it and runs it. It also facilitates testing. You can instantiate the object you want to test and feed it mock objects for all its dependencies, but when it runs as a composed application, the composition process automatically hooks all the real objects together.
The most important point I'd like to mention is that even though System.Addins is in the framework already, I don't see a lot of evidence of people using it, but MEF is just sitting there on CodePlex supposedly to be included in .NET 4, and people are already starting to build lots of applications with it (myself included). I think that tells you something about the two frameworks.
На мой взгляд, две технологии на самом деле нацелены на очень разные варианты использования.
MEF обычно лучше всего подходит для сценария внедрения чистой зависимости, когда человек или группа, доставляющие окончательное интегрированное решение, собирают все и ручаются за общую целостность, но нуждаются в различных реализациях ключевых возможностей.
MAF предназначен для сценарий, в котором кто-то / группа разрабатывает платформу или хост, а другие группы добавят возможности постфактум и способом, не контролируемым группой хостов. В этом сценарии необходимы более сложные механизмы для «защиты» хоста от несанкционированных надстроек (или защиты надстроек друг от друга).
Третьей похожей по шаблону технологией является вся схема ProviderBase. Это также позволяет заменить возможность, но на самом деле ее целью является сценарий, в котором хосту / приложению абсолютно необходима возможность, и действительно необходимо указать различные реализации через config.
Я только что нашел эту длинную статью, в которой обсуждаются как MAF, так и MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/
В дополнение к пунктам, высказанным другими ответами, похоже, что один из Ключевые различия между MEF и MAF заключаются в том, что структура управляемой расширяемости позволяет одной компонуемой части зависеть от другой. Например, это позволит подключаемому модулю зависеть от другого подключаемого модуля.
Платформа Managed Extensibility Framework также не делает различий между хостом и надстройкой, как это делает System.AddIn. Что касается MEF, то все они просто составные части.
Разработав и отправив приложение MAF. Мои взгляды на MAF несколько пресыщены.
MAF - это "несвязанная" система или в худшем случае "слабосвязанная" система. MEF - это в лучшем случае «связанная» система или «слабосвязанная» система.
Преимущества MAF, которые мы реализовали с помощью MAF:
Установка новых или обновление существующих компонентов во время работы приложения. Надстройку можно обновлять во время работы приложения, и обновления отображаются пользователю без проблем. Для этого у вас должны быть домены приложений.
Лицензирование на основе приобретенных компонентов. Мы могли контролировать, какие надстройки были загружены с помощью роли и разрешений пользователя, а также была ли надстройка лицензирована для использования.
Быстрая разработка (более быстрый вывод на рынок). Разработка надстроек идеально сочетается с методологией Agile, команда разработчиков разрабатывала по одной надстройке за раз, без необходимости также разрабатывать часть интеграции с остальной частью приложения.
Улучшенный контроль качества (только контроль качества по одному компоненту за раз). Затем QA может протестировать и выявить дефекты для одного бита функциональности. Тестовые примеры было легче разрабатывать и внедрять.
Развертывание (добавляйте компоненты по мере их разработки и выпуска, и они «просто работают»). Развертывание сводится только к созданию надстройки и установке файла. Никаких других соображений не требовалось!
Новые компоненты работали со старыми компонентами. Надстройки, которые были разработаны на раннем этапе, продолжали работать. Новые надстройки легко вписываются в приложение