Каковы преимущества и недостатки использования GAC?
Вот пример использования контроллера, введенного Guice.
/**
* Loads a FXML file and injects its controller from the given Guice {@code Provider}
*/
public abstract class GuiceFxmlLoader {
public GuiceFxmlLoader(Stage stage, Provider<?> provider) {
mStage = Objects.requireNonNull(stage);
mProvider = Objects.requireNonNull(provider);
}
/**
* @return the FXML file name
*/
public abstract String getFileName();
/**
* Load FXML, set its controller with given {@code Provider}, and add it to {@code Stage}.
*/
public void loadView() {
try {
FXMLLoader loader = new FXMLLoader(getClass().getClassLoader().getResource(getFileName()));
loader.setControllerFactory(p -> mProvider.get());
Node view = loader.load();
setViewInStage(view);
}
catch (IOException ex) {
LOGGER.error("Failed to load FXML: " + getFileName(), ex);
}
}
private void setViewInStage(Node view) {
BorderPane pane = (BorderPane)mStage.getScene().getRoot();
pane.setCenter(view);
}
private static final Logger LOGGER = Logger.getLogger(GuiceFxmlLoader.class);
private final Stage mStage;
private final Provider<?> mProvider;
}
Вот конкретная реализация загрузчика:
public class ConcreteViewLoader extends GuiceFxmlLoader {
@Inject
public ConcreteViewLoader(Stage stage, Provider<MyController> provider) {
super(stage, provider);
}
@Override
public String getFileName() {
return "my_view.fxml";
}
}
Обратите внимание, что этот пример загружает представление в центр BoarderPane, который является корнем сцены в рабочей области. Это не относится к примеру (деталь реализации моего конкретного варианта использования), но решил оставить его, поскольку некоторые из них могут оказаться полезными.
7 ответов
Если вы отправляете повторно используемую библиотеку, состоящую из нескольких сборок, но лишь некоторые из них образуют фасад, вы можете рассмотреть возможность установки сборок в GAC, если пакет установлен на ПК разработчика.
Представьте, что вы отправляете 6 сборок, и только одна из этих 6 сборок содержит фасад, то есть остальные 5 используются только самим фасадом. Вы отправляете:
- MyProduct.Facade.dll - это единственный компонент, предназначенный для использования разработчиками
- MyProduct.Core.dll - используется MyProduct.Facade.dll, но не предназначен для использования разработчиками
- MyProduct.Component1.dll - то же
- MyProduct.Component2.dll - то же
- ThirdParty.Lib1.dll - сторонняя библиотека, используемая MyProduct.Component1.dll
- ThirdParty.Lib2.dll - то же
- и др.
Разработчики, использующие ваш проект, хотели бы ссылаться только на MyProduct.Facade.dll в своих проектах. Но когда их проект запускается, он должен иметь возможность загружать все сборки, на которые он ссылается, - рекурсивно. Как этого добиться? Как правило, они должны быть доступны либо в папке Bin, либо в GAC:
- Вы можете попросить разработчиков найти вашу установочную папку и добавить ссылки на все N сборки, которые вы туда поместили. Это гарантирует, что они будут скопированы в папку Bin и будут доступны во время выполнения.
- Вы можете установить шаблон проекта VS.NET , уже содержащий эти 6 ссылок . Это немного сложно, так как вы должны ввести фактический путь к вашим сборкам в этот шаблон до его установки. Это может сделать только установщик, поскольку этот путь зависит от пути установки.
- Вы можете попросить разработчиков создать специальный шаг после сборки в файле .csproj / .vbproj , скопировав необходимые зависимости в папку Bin. Те же недостатки.
- Наконец, вы можете установить все свои сборки в GAC . В этом случае разработчики должны добавить ссылку только на MyProduct.Facade.dll из своего проекта. Все остальное в любом случае будет доступно во время выполнения.
Примечание: последний вариант не заставляет вас делать то же самое при отправке проекта на производственные ПК. Вы можете отправить все сборки в папку Bin или установить их в GAC - все зависит от вашего желания.
Таким образом, описанное решение показывает преимущество помещения сторонних сборок в GAC во время разработки. Это не связано с производством.
Как видите, установка в GAC в основном предназначена для решения проблемы размещения необходимых сборок (зависимостей). Если сборка установлена в GAC, вы можете считать, что она существует «рядом» с любым приложением. Это похоже на добавление пути к .exe к переменной PATH, но «управляемым способом». - конечно, это довольно упрощенное описание;)
- Загружающиеся блоки от GAC означают меньше служебное и безопасность, что Ваше приложение будет всегда загружать правильную версию библиотеки.NET
- , Вы не были должны ngen блоки, которые являются за пределами GAC, потому что не будет почти никакого увеличения производительности, во многих случаях даже потеря в производительности.
- Вы уже используете GAC, потому что все стандартные блоки.NET находятся на самом деле в GAC и ngened (во время установки).
- Используя GAC для Ваших собственных библиотек добавляет сложность в развертывание, я старался бы избегать его любой ценой.
- Ваши пользователи должны быть зарегистрированы как администраторы во время установки, если Вы хотите поместить что-то в GAC, настоящую проблему для многих типов приложений.
Так для подведения итогов всего этого запустите простой и если Вы позже видите основное увеличение производительности при помещении блоков в GAC и NGEN их пойдите для него, иначе не беспокойтесь. GAC более подходит для платформ, где существует ожидание библиотеки, чтобы быть общим для больше приложений в 99% случаев, Вам не нужен он.
Преимущество:
- Только одно место для обновления блоков
- Вы используете немного меньше пространства на жестком диске
Недостаток:
- , Если необходимо обновить только один веб-сайт, Вы не можете. Можно закончить другими веб-сайтами в веб-сервере, поврежденном
Рекомендация: Оставьте GAC MS и друзьям. Гигабайт является очень дешевым теперь.
GAC может также использоваться блоками, которые требуют поднятых полномочий выполнить привилегированные операции от имени менее доверяемого кода (например, частичное доверительное приложение ASP.NET).
, Например, скажите, что у Вас есть частичное доверительное приложение ASP.NET, которое должно выполнить задачу, которая потребовала бы поднятых полномочий, т.е. Полное Доверие . Решение состоит в том, чтобы поместить код, который требует поднятых полномочий в отдельный блок. Блок отмечен с эти AllowPartiallyTrustedCallers атрибут и класс, который содержит привилегированную логику, отмечен с атрибутом PermissionSet, чем-то вроде этого:
[PermissionSet(SecurityAction.Assert, Unrestricted=true)]
Нашему блоку дали бы поставленную строгую подпись и затем развернутую в GAC.
Теперь наше частично доверяемое приложение (приложения) может использовать доверяемый блок в GAC для выполнения определенного и узкого набора привилегированных операций, не теряя преимущества частичного доверия.
Выполнения GAC с Полным Доверием и могут использоваться приложениями за пределами Вашего веб-приложения. Например, Timer Jobs в Sharepoint должны быть в GAC, потому что sptimer обслуживание является отдельным процессом.
"Полная Доверительная" Часть является также возможным источником для проблем безопасности. Несомненно, можно работать с Безопасностью доступа к коду, но я не вижу, что слишком много блоков используют CAS, к сожалению: (/Папка мусорного ведра может быть заблокирована вниз к Носителю, который обычно прекрасен.
Daniel Larson имеет сообщение на CAS также , который детализирует различия немного больше.
Я думаю, что одно из самых больших преимуществ использования GAC - то, что у Вас может быть несколько версий того же блока, зарегистрированного и доступного Вашим приложениям. Лично, мне не нравится, как это ограничивает перемещение с машины на машину (мне не нравится иметь необходимость сказать, проверить источник на новый VPC и пройти набор шагов для получения его выполнение, потому что я должен зарегистрировать материал в GAC)
За всю свою жизнь у меня было, возможно, одно приложение, куда я должен был поместить блок в GAC, просто потому что эти блоки были частью платформы, что много приложений будут использовать его, и это казалось правильным для помещения их в GAC.