ChapterÂ 6.Â Lightweight Containers and Inversion of Control
Applications need an infrastructural backbone. We can't responsibly dispense with EJB in medium to large-scale J2EE applications without providing an alternative way of managing business objects. Fortunately, good alternatives exist, and we'll discuss some in this chapter.
Management of business objects will typically involve some form of container. We can try to do without a container, and without an overall application framework, but this is unwise. It typically leads into a morass of an ad hoc mix of Singletons, custom-coded factories, and inconsistent handling of configuration. Some developers might use properties files to hold configuration; others might prefer XML documents or the database. It's likely to be hard to identify a clear service layer in the application, and the overall lack of consistency will prove costly in maintenance.
EJB brings some order in the face of this potential chaos, and if we want to do without EJB, we must provide order and structure in other ways. An EJB container provides a well-defined service layer (normally of SLSBs). It also provides a partial solution for managing business objects. We say "partial" because it leads to complication on the client side, as accessing EJBs is difficult and requires infrastructure itself; because EJB doesn't make it easy to externalize configuration data; and because an EJB container doesn't help to manage fine-grained objects such as DAOs. Even if we use ...