BeanFactory vs ApplicationContext
Jestem całkiem nowy w Spring Framework, bawiłem się nim i składałem kilka przykładowych aplikacji w celu oceny Spring MVC do wykorzystania w nadchodzącym projekcie firmy. Jak na razie bardzo podoba mi się to, co widzę w Spring MVC, wydaje się bardzo łatwe w użyciu i zachęca do pisania klas, które są bardzo przyjazne dla testów jednostkowych.
Jako ćwiczenie piszę główną metodę dla jednego z moich przykładowych/testowych projektów. Jedno, co nie jest jasne, to dokładne różnice między BeanFactory
i ApplicationContext
- które są odpowiednie do stosowania w jakich warunkach?
Rozumiem, że ApplicationContext
rozszerza BeanFactory
, ale jeśli piszę tylko prostą metodę główną, Czy potrzebuję dodatkowej funkcjonalności, która zapewnia ApplicationContext
? A jakie dodatkowe funkcje zapewnia ApplicationContext
?
Oprócz odpowiedzi "które powinienem użyć w metodzie main ()", czy są jakieś standardy lub wytyczne odnośnie tego, którą implementację powinienem zastosować w takim scenariuszu? Czy moja główna metoda() powinna być napisane w zależności od konfiguracji bean/application, aby być w formacie XML - czy to bezpieczne założenie, czy też zamykam użytkownika w coś konkretnego?
I czy ta odpowiedź zmienia się w środowisku sieciowym - jeśli któraś z moich klas musiała być świadoma Springa, to czy będą bardziej potrzebowali ApplicationContext
?
22 answers
Spring docs są świetne na tym: 3.8.1. BeanFactory czy Applicationkontekst?. Mają tabelkę z porównaniem, wrzucę fragment:
Fabryka Fasoli
- instancja fasoli / okablowanie
Kontekst Aplikacji
- instancja fasoli / okablowanie
- Automatyczna rejestracja BeanPostProcessor
- Automatyczna rejestracja BeanFactoryPostProcessor
- wygodny dostęp do MessageSource (dla i18n)
- ApplicationEvent publication
Więc jeśli potrzebujesz któregokolwiek z punktów prezentowanych po stronie kontekstu aplikacji, powinieneś użyć ApplicationContext.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-28 14:04:37
Dla mnie, podstawową różnicą do wyboru BeanFactory
nad ApplicationContext
wydaje się być to, że ApplicationContext
będzie pre-instantiate wszystkie ziarna. Z Wiosna docs:
Spring ustawia właściwości i rozwiązuje zależności tak późno, jak to możliwe, gdy fasola jest rzeczywiście utworzona. Oznacza to, że kontener Spring, który poprawnie załadował się, może później wygenerować wyjątek podczas żądania obiektu, jeśli wystąpi problem z wytworzeniem tego obiektu lub jednej z jego zależności. Na przykład bean wyrzuca wyjątek w wyniku braku lub nieprawidłowej właściwości. Potencjalnie opóźniona widoczność niektórych problemów z konfiguracją jest powodem, dla którego implementacje ApplicationContext domyślnie tworzą instancję singleton beans. Kosztem trochę czasu z góry i pamięci do tworzenia tych fasoli, zanim są one rzeczywiście potrzebne, można odkryć problemy konfiguracyjne podczas tworzenia ApplicationContext, nie później. Nadal możesz nadpisać to domyślne zachowanie tak, że singleton Beans będzie leniwy-initialize, zamiast być wstępnie utworzone.
Biorąc to pod uwagę, początkowo wybrałem BeanFactory
do wykorzystania w testach integracji/wydajności, ponieważ nie chciałem ładować całej aplikacji do testowania izolowanych fasoli. Jednak -- i ktoś mnie poprawi jeśli się mylę -- BeanFactory
nie obsługuje classpath
konfiguracji XML. Tak więc BeanFactory
i ApplicationContext
każdy z nich zapewnia kluczową cechę, której chciałem, ale ani jedno, ani drugie.
Z tego co wiem, notatka w dokumentacji o nadpisywaniu domyślnej instancji zachowanie odbywa się w konfiguracji i jest per-bean, więc nie mogę po prostu ustawić atrybutu" lazy-init " w pliku XML lub utknąłem utrzymując jego wersję do testów i jedną do wdrożenia.
Skończyło się na tym, że rozszerzyłem ClassPathXmlApplicationContext
na leniwe Ładowanie fasoli do wykorzystania w testach takich jak tak:
public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {
public LazyLoadingXmlApplicationContext(String[] configLocations) {
super(configLocations);
}
/**
* Upon loading bean definitions, force beans to be lazy-initialized.
* @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
*/
@Override
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
super.loadBeanDefinitions(reader);
for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
beanDefinition.setLazyInit(true);
}
}
}
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-14 19:40:12
Spring dostarcza dwa rodzaje kontenerów IOC, jeden to
XMLBeanFactory
, a drugi toApplicationContext
.
+---------------------------------------+-----------------+--------------------------------+
| | BeanFactory | ApplicationContext |
+---------------------------------------+-----------------+--------------------------------+
| Annotation support | No | Yes |
| BeanPostProcessor Registration | Manual | Automatic |
| implementation | XMLBeanFactory | ClassPath/FileSystem/WebXmlApplicationContext|
| internationalization | No | Yes |
| Enterprise services | No | Yes |
| ApplicationEvent publication | No | Yes |
+---------------------------------------+-----------------+--------------------------------+
-
FileSystemXmlApplicationContext
fasola załadowana pełną ścieżką. -
ClassPathXmlApplicationContext
Beans loaded through the CLASSPATH -
XMLWebApplicationContext
iAnnotationConfigWebApplicationContext
beans ładowane przez kontekst aplikacji webowej. -
AnnotationConfigApplicationContext
Ładowanie fasoli wiosennej z konfiguracji opartej na adnotacjach.
Przykład:
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);
-
ApplicationContext
jest pojemnikiem inicjowane przezContextLoaderListener
lubContextLoaderServlet
zdefiniowane wweb.xml
iContextLoaderPlugin
zdefiniowane wstruts-config.xml
.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-22 12:54:56
Aby dodać do tego, na co odpowiedział Miguel Ping, Oto kolejna sekcja z dokumentacji, która również na to odpowiada:
Skrócona wersja: użyj ApplicationContext, chyba że masz naprawdę dobry powód, aby tego nie robić. Dla tych z Was, którzy szukają nieco większej głębi co do "ale dlaczego" powyższego zalecenia, Czytaj dalej.
(zamieszczam to dla przyszłych wiosennych nowicjuszy, którzy mogą przeczytać to pytanie)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-28 14:08:23
ApplicationContext
jest bardziej preferowany sposób niżBeanFactory
-
W nowych wersjach wiosennych
BeanFactory
zastępuje sięApplicationContext
. Ale nadalBeanFactory
istnieje dla wstecznej kompatybilności -
ApplicationContext extends BeanFactory
i ma następujące zalety- obsługuje internacjonalizację dla wiadomości tekstowych
- obsługuje publikację zdarzeń dla zarejestrowanych słuchaczy
- dostęp do zasobów, takich jak adresy URL i pliki
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-14 19:23:29
Myślę, że lepiej zawsze używać ApplicationContext, chyba że jesteś w środowisku mobilnym, jak ktoś już powiedział. ApplicationContext ma większą funkcjonalność i zdecydowanie chcesz użyć postprocesorów takich jak RequiredAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor i CommonAnnotationBeanPostProcessor, które pomogą Ci uprościć swoje pliki konfiguracyjne Spring i możesz używać adnotacji takich jak @Required, @ PostConstruct, @Resource, itp. fasola.
Nawet jeśli nie używasz wszystkich rzeczy, które oferuje ApplicationContext, lepiej i tak go używać, a później, jeśli zdecydujesz się użyć niektórych rzeczy zasobów, takich jak wiadomości lub post procesory, lub innego schematu, aby dodać porady transakcyjne i takie, będziesz już mieć ApplicationContext i nie trzeba zmieniać żadnego kodu.
Jeśli piszesz samodzielną aplikację, załaduj ApplicationContext w swojej głównej metodzie, używając ClassPathXmlApplicationContext i pobierz główną bean i wywołaj jego run () (lub inną metodę), aby uruchomić aplikację. Jeśli piszesz aplikację internetową, użyj contextloaderlistener in web.xml, aby wytworzyć ApplicationContext i można go później pobrać z ServletContext, niezależnie od tego, czy używasz JSP, JSF, JSTL, struts, Tapestry, itp.
Pamiętaj również, że możesz użyć wielu plików konfiguracyjnych Spring i możesz utworzyć ApplicationContext listując wszystkie pliki w konstruktorze (lub listując je w context-param dla ContextLoaderListener), lub możesz po prostu załadować główny plik konfiguracyjny, który zawiera instrukcje import. Możesz zaimportować plik konfiguracyjny sprężyny do innego pliku konfiguracyjnego sprężyny za pomocą
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-11-04 18:39:56
- BeanFactory: nie obsługuje iniekcji zależności opartych na adnotacjach.
- ApplicationContext: Obsługa iniekcji zależności opartych na adnotacjach. - @Autowired, @ PreDestroy
- BeanFactory: nie obsługuje
- ApplicationContext: konteksty aplikacji mogą publikować zdarzenia do fasoli, które są zarejestrowane jako słuchacze
- BeanFactory: nie obsługuje sposobu dostępu do pakietu komunikatów(internationalization (I18N)
- ApplicationContext: Obsługa komunikatów internacjonalizacji (I18N).
- BeanFactory: nie obsługuje.
- Applicationkontekst: obsługuje wiele usług korporacyjnych, takich jak dostęp do JNDI, integracja EJB, remoting.
- BeanFactory: domyślnie obsługuje leniwe ładowanie
- ApplicationContext: domyślnie obsługuje agresywne Ładowanie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-09-27 19:26:22
ApplicationContext: Ładuje fasolę wiosenną skonfigurowaną w pliku konfiguracyjnym spring i zarządza cyklem życia fasoli wiosennej jako i kiedy kontener STARTS.It nie będzie czekać aż zostanie wywołane getBean("springbeanref").
BeanFactory Ładuje fasolę wiosenną skonfigurowaną w pliku konfiguracyjnym spring, zarządza cyklem życia fasoli wiosennej, gdy wywołujemy getBean ("springbeanref") . więc kiedy wywołujemy getBean("springbeanref") w momencie rozpoczyna się cykl życia fasoli wiosennej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-06-04 07:15:46
W większości przypadków preferowane jest ApplicationContext, chyba że trzeba oszczędzać zasoby, np. w aplikacji mobilnej.
Nie jestem pewien w zależności od formatu XML, ale jestem prawie pewien, że najczęstsze implementacje ApplicationContext są te XML, takie jak ClassPathXmlApplicationContext, XmlWebApplicationContext i FileSystemXmlApplicationContext. To jedyne trzy, z których korzystałem.
Jeśli tworzysz aplikację internetową, można śmiało powiedzieć, że będziesz musiał użyć XmlWebApplicationContext.
Jeśli chcesz, aby Twoje fasolki były świadome Springa, możesz je zaimplementować BeanFactoryAware i / lub ApplicationContextAware, więc możesz użyć BeanFactory lub ApplicationContext i wybrać interfejs do zaimplementowania.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-28 21:02:39
BeanFactory i ApplicationContext oba sposoby na pozyskanie fasoli z pojemnika spring IOC , ale nadal istnieje pewna różnica.
BeanFactory jest rzeczywistym kontenerem, który tworzy instancje, konfiguruje i zarządza szeregiem bean ' s. te ziarna zazwyczaj współpracują ze sobą, a zatem mają zależności między sobą. Zależności te znajdują odzwierciedlenie w danych konfiguracyjnych używanych przez BeanFactory.
Beanfactory i ApplicationContext Oba są interfejsami Java, a ApplicationContext rozszerza BeanFactory. Oba są konfiguracją za pomocą plików konfiguracyjnych XML. W skrócie BeanFactory zapewnia podstawową inwersję funkcji control ( IoC) i Dependency Injection (DI), podczas gdy ApplicationContext zapewnia zaawansowane funkcje.
BeanFactory jest reprezentowany przez interfejs " org.springframework.fasola.fabryka " Gdzie BeanFactory, dla których istnieje wiele implementacji.
ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);
Różnica
Beanfactory instantiate bean wywołanie metody getBean () podczas ApplicationContext instantiate Singleton bean po uruchomieniu kontenera nie czeka na wywołanie getBean ().
BeanFactory nie zapewnia wsparcia dla internacjonalizacji, ale ApplicationContext zapewnia wsparcie dla to.
Kolejną różnicą między BeanFactory A ApplicationContext jest możliwość publikowania zdarzeń do fasoli, które są zarejestrowane jako listener.
Jedną z popularnych implementacji beanfactory interface jest XMLBeanFactory, natomiast jedną z popularnych implementacji ApplicationContext interface jest ClassPathXmlApplicationContext.
Jeśli używasz automatycznego okablowania i używasz BeanFactory Następnie musisz zarejestrować AutoWiredBeanPostProcessor za pomocą API, które możesz skonfigurować w XML, jeśli używasz ApplicationContext . Podsumowując BeanFactory jest w porządku do testowania i nie produkcji, ale ApplicationContext jest bardziej rozbudowaną implementacją kontenerów i powinna być faworyzowana przez BeanFactory
BeanFactory domyślnie obsługuje Lazy wczytywanie i ApplicationContext domyślnie obsługa wczytywanie .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-18 01:20:13
Macierz funkcji fabryki fasoli vs kontekst aplikacji ]}
zrzut ekranu funkcji BeanFacotry i ApplicationContext
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-22 06:46:18
Różnice między BeanFactory i ApplicationContext są następujące:
- BeanFactory używa leniwej inicjalizacji , ale ApplicationContext używa chętnej inicjalizacji. W przypadku BeanFactory, bean jest tworzony podczas wywołania metody getBeans (), ale bean jest tworzony z góry w przypadku ApplicationContext podczas tworzenia obiektu ApplicationContext.
- BeanFactory jawnie dostarcza obiekt zasobu używając składni ale ApplicationContext samodzielnie tworzy i zarządza obiektami zasobów.
- BeanFactory nie obsługuje internatiolizacji , ale ApplicationContext obsługuje internacjonalizację.
- z BeanFactory iniekcja zależności oparta na adnotacjach nie jest obsługiwana , ale iniekcja zależności oparta na adnotacjach JEST OBSŁUGIWANA W ApplicationContext.
Korzystanie Z BeanFactory:
BeanFactory beanfactory = new XMLBeanFactory(new FileSystemResource("spring.xml"));
Triangle triangle =(Triangle)beanFactory.getBean("triangle");
Korzystanie Z ApplicationContext:
ApplicationContext context = new ClassPathXMLApplicationContext("spring.xml")
Triangle triangle =(Triangle)beanFactory.getBean("triangle");
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-10-01 16:19:46
Zasadniczo możemy utworzyć obiekt kontenera spring na dwa sposoby
- Korzystanie z BeatFactory
- używanie ApplicationContext
Oba są interfejsami
Używając klas implementacyjnych możemy stworzyć obiekt dla kontenera spring
Coming to the differences
BeanFactory
Nie obsługuje iniekcji zależności opartych na adnotacjach.
-
Nie obsługuje I18N
-
Domyślnie jego obsługa loading
Nie pozwala na konfigurację do wielu plików konfiguracyjnych.
Ex: beanfactory context = new XmlBeanFactory (new Resource ("applicationContext.xml"));
ApplicationContext
-
Obsługa iniekcji zależności opartych na adnotacjach.- @Autowired, @ PreDestroy
-
Obsługa I18N
Jego domyślnie obsługuje agresywne Ładowanie.
Pozwala na konfigurację wielu konfiguracji pliki.
Ex:
ApplicationContext context = new ClasspathXmlApplicationContext ("applicationContext.xml");
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-18 05:59:53
A. różnica między fabryką bean a kontekstem aplikacji jest taka, że former tworzy instancję bean, gdy wywołujesz metodę getBean (), podczas gdy ApplicationContext tworzy instancję Singleton bean, gdy kontener jest uruchomiony, nie czeka na wywołanie getBean.
B.
ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
Lub
ApplicationContext context = new ClassPathXmlApplicationContext{"spring_dao.xml","spring_service.xml};
Możesz użyć jednego lub więcej plików xml w zależności od wymagań projektu. Jak tu używam dwóch plików xml tj. jeden dla szczegółów konfiguracji dla klas usług innych dla dao klasy. Tutaj ClassPathXmlApplicationContext jest potomkiem ApplicationContext.
C. kontener BeanFactory jest kontenerem podstawowym, może tworzyć tylko obiekty i wstrzykiwać zależności. Ale nie możemy dołączyć innych usług, takich jak bezpieczeństwo, transakcje, wiadomości itp. aby świadczyć wszystkie usługi musimy użyć ApplicationContext Container.
D. BeanFactory nie zapewnia wsparcia dla internacjonalizacji tj. i18n, ale ApplicationContext zapewnia wsparcie dla niego.
E. Kontener BeanFactory nie obsługuje funkcji automatycznego skanowania (Obsługa iniekcji zależności opartych na adnotacjach), ale kontener ApplicationContext obsługuje.
F. kontener Beanfactory nie utworzy obiektu bean do czasu żądania. Oznacza to, że pojemnik Beanfactory leniwie ładuje fasolę. Podczas gdy ApplicationContext Container tworzy obiekty Singleton bean tylko w czasie ładowania. Oznacza to, że jest wczesne Ładowanie.
Pojemnik G. Beanfactory obsługuje tylko dwa zakresy (singleton & prototype ) of the beans. Ale ApplicationContext Container obsługuje cały zakres beans.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-03-21 22:58:44
Beanfactory używa metody lazy initialization, podczas gdy ApplicationContext używa metody eager initialization . tzn. beanfactory tworzy singleton bean tylko wtedy, gdy jest z niego wymagane, ale ApplicationContext tworzy wszystkie singleton Bean w czasie własnej inicjalizacji.
-
ApplicationContext tworzy i zarządza obiektami resources samodzielnie, podczas gdy beanfactory jawnie dostarczał obiekt resource używając składni :
ClassPathResource resource = new ClassPathResource("beans.xml"); XmlBeanFactory factory = new XmlBeanFactory(resource); // Here resource object is provided explicitly
ApplicationContext obsługuje internacjonalizację, ale BeanFactory nie.
Iniekcja zależności oparta na adnotacjach nie jest obsługiwana przez BeanFactory, podczas gdy ApplicationContext obsługuje używanie adnotacji @PreDestroy, @Autowired.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-03-29 07:53:42
Zwróć ten dokument Z Spring Docs:
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-introduction-ctx-vs-beanfactory
5.15.1 BeanFactory czy Applicationkontekst?
Użyj ApplicationContext, chyba że masz ku temu dobry powód.
Ponieważ ApplicationContext zawiera wszystkie funkcje BeanFactory, jest ogólnie zalecany przez BeanFactory, z wyjątkiem kilku sytuacje takie jak aplet, w których zużycie pamięci może być krytyczne i kilka dodatkowych kilobajtów może mieć znaczenie. Jednak w przypadku większości typowych aplikacji i systemów korporacyjnych, Applicationkontekst jest tym, czego chcesz użyć. Spring 2.0 i nowsze mocno wykorzystuje punkt rozszerzenia BeanPostProcessor (aby efekt proxy i tak dalej). Jeśli używasz tylko zwykłej fabryki BeanFactory, spora ilość wsparcia, takiego jak transakcje i AOP, nie wejdzie w życie, przynajmniej nie bez dodatkowych kroki z twojej strony. Ta sytuacja może być myląca, ponieważ nic nie jest tak naprawdę źle z konfiguracją.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-30 08:52:25
Różnica między BeanFactory a ApplicationContext:
Org.springframework.fasola.fabryka.BeanFactory i org.springframework.kontekst.Applicationkontekst interfaces działa jako kontener IoC. Interfejs ApplicationContext jest zbudowany na bazie interfejsu BeanFactory. Dodaje kilka dodatkowych funkcji niż BeanFactory, takich jak prosta integracja z AOP Spring, obsługa zasobów wiadomości( dla I18N), propagacja zdarzeń, kontekst specyficzny dla warstwy aplikacji (np. Webaplicationcontext) dla aplikacji webowej. Więc lepiej jest użyć ApplicationContext niż BeanFactory.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-18 07:18:51
ApplicationContext jest wielkim bratem BeanFactory i to wszystko, co oferuje BeanFactory, a także wiele innych rzeczy.
Oprócz standardowego org.springframework.fasola.fabryka.Możliwości cyklu życia BeanFactory, implementacje ApplicationContext wykrywają i wywołaj ApplicationContextAware beans, a także ResourceLoaderAware, ApplicationEventPublisherAware i MessageSourceAware beans.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-26 06:52:30
W scenariuszu czasu rzeczywistego różnica między Spring IOC Core container (BeanFactory) a advanced J2EE container (ApplicationContext) jest następująca.
BeanFactory stworzy obiekty dla fasoli (np. dla klas POJO) wymienionych na wiosnę.plik xml (
<bean></bean>
) tylko wtedy, gdy wywołujesz .metoda getBean (), ale ApplicationContext tworzy obiekty dla wszystkich beans (<bean></bean>
jeśli jego zakres nie jest jawnie wymieniony jako "Prototype") skonfigurowanych w wiosna.xml podczas ładowania sprężyny.sam plik xml.-
BeanFactory: (leniwy kontener, ponieważ tworzy obiekty dla beans tylko wtedy, gdy jawnie wywołujesz z klasy user/main)
/* * Using core Container - Lazy container - Because it creates the bean objects On-Demand */ //creating a resource Resource r = (Resource) new ClassPathResource("com.spring.resources/spring.xml"); //creating BeanFactory BeanFactory factory=new XmlBeanFactory(r); //Getting the bean for the POJO class "HelloWorld.java" HelloWorld worldObj1 = (HelloWorld) factory.getBean("test");
ApplicationContext: (Eager container ze względu na tworzenie obiektów wszystkich ziaren singleton podczas ładowania sprężyny.sam plik xml)
ApplicationContext context = new ClassPathXmlApplicationContext("com/ioc/constructorDI/resources/spring.xml");
Technicznie zaleca się stosowanie ApplicationContext, ponieważ w aplikacjach w czasie rzeczywistym obiekty bean będą stworzony podczas uruchamiania aplikacji na samym serwerze. Skraca to czas odpowiedzi na żądanie użytkownika, ponieważ obiekty są już dostępne do odpowiedzi.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-02-26 01:41:26
Myślę, że warto wspomnieć, że od wiosny 3, Jeśli chcesz stworzyć fabrykę, możesz również użyć @configuration
adnotacja połączona z właściwą @scope
@Configuration
public class MyFactory {
@Bean
@Scope("prototype")
public MyClass create() {
return new MyClass();
}
}
Twoja fabryka powinna być widoczna przez Pojemnik sprężynowy za pomocą @ComponentScan
Adnotacja lub Konfiguracja xml
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-01-23 13:00:10
Używaj BeanFactory dla aplikacji innych niż web, ponieważ obsługuje tylko Singleton i Prototype Bean-scopes.
Podczas gdy kontener ApplicationContext obsługuje wszystkie zakresy Bean, powinieneś go używać w aplikacjach internetowych.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-04-21 22:01:44
W podsumowaniu:
ApplicationContext zawiera wszystkie funkcje BeanFactory. Ogólnie zaleca się stosowanie tego pierwszego.
Istnieją pewne ograniczone sytuacje, takie jak w aplikacji mobilnej, gdzie zużycie pamięci może być krytyczne.
W tym scenariuszu można uzasadnić użycie bardziej lekkiego BeanFactory . Jednak w większości aplikacji korporacyjnych aplikacja ApplicationContext jest tym, co chcesz użyj.
Więcej o:
Różnica między BeanFactory i ApplicationContext na wiosnę-blog java spring od podstaw
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-07-07 17:25:12