Introduction to the ApplicationContext - Spring Framework Tutorial

- [Instructor] The Application Context and more specifically, the BeanFactory is one of the most important components of the Spring Framework. As we dig in deeper to the Framework as a whole, we need to fully understand the application context and the role it plays during runtime of our applications. The first thing that we need to discuss is the purpose of the application context. The application context acts as the heart of the SpringApplication. This is the central element that you deal with from the Spring Framework when developing an application. As previously mentioned, your classes should seldom, if ever, have imports from the Spring Framework, except in the few cases of annotations. However, the application context and the entry point of your application is an exception. The application context encapsulates the BeanFactory. The BeanFactory, as we will discuss, is the IoC container itself. The application context encapsulates it to provide a user access to the BeanFactory under very controlled situations. As such, it provides metadata for bean creation. We will talk a lot about bean configuration, but no matter the mechanism that you use to configure your beans, the application context serves to take that configuration and to allow the framework to use it to build the IoC container itself. It also ensures that your beans are created in appropriate order as we saw previously. This can be a concern when a central object manages all of the dependencies in an application. It must be done in proper order to ensure dependencies are available when needed for the construction of objects. Spring handles that through mechanisms within the BeanFactory and ultimately the application context. As mentioned, the BeanFactory provides for the inversion of control container. This provides all the facilities for injection of beans at startup and runtime. While most beans are singletons and injected at startup, there are other types of beans that get handled slightly differently, however. All of the injection is handled by the BeanFactory. Most of the developers interaction with Spring is actually configuring the IoC container. We do use abstractions provided by Spring, but they are just pre-configured facades on top of repetitive processes for the most part. Really using Spring is more about configuration, at least at its core. The BeanFactory maintains a handle to all singleton beans in the application. Now, what this means is that beans of type singleton will always be referenced in the BeanFactory. Even if a class goes out of scope in the main runtime, the BeanFactory will always have a handle to it. This also means that the instance object is injected everywhere it is used, so you need to keep that in account when storing state in these objects. Attributes for these classes must be handled carefully. Beans that aren't singletons are handled differently, and we'll talk about those a little later on. Multiple application contexts can bring a little bit more challenge to your application and we need to at least mention that they're there. A spring application can have more than one application context. It will always have at least one, but in certain situations there can exist multiple. Web containers, for instance, always have multiple application contexts in play. The parent context can interact with the child context, but the other is not usually possible. This makes sense if you think about OOP in general because there is always a parent context and the rest are children, much like a dependency graph for your business objects. We aren't going to go into too much depth here on multiple application contexts, however. Because most often it is the framework that is controlling these cases.