＋设为首页 ＋添加到收藏夹
within the web world, you wont find too many web applications that arent built on top of the likes of model view controller, business delegate, session facade, data access object, or other patterns these days. these patterns have been used to form architectures that attempt to provide a stronger foundation for our applications. by utilizing some of these patterns together, we avoid the problems faced by past development efforts, and provide extensibility for future growth. however, one problem still remains: component dependency resolution.
terminology 【程序编程相关:Java Tech: Language 】in this article, we will take a look at the problem in more depth and learn how others have tried to solve the problem by utilizing frameworks that implement the inversion of control (or ioc) pattern. first, well become familiar with some terms, the ioc pattern, and other patterns that have tried to implement a solution (but didnt completely succeed). then well move on, to see how two of the most popular ioc frameworks are used today. these frameworks are picocontainer and hivemind. 【推荐阅读:From Writing Program】
i dont want you to become hung up on these terms while trying to understand the concepts youre about to meet, since these terms change from time to time to mean different things. regardless of what you are trying to connect, the problem still remains, and hopefully, the solution will still hold as well. 【扩展信息:The Java Extension M】
throughout the remainder of this article, well refer to components, services, and classes interchangeably. in a more realistic setting, components could mean self-reliant pieces of code that are made up of various classes in order to provide a local reusable service. you could also say that the word "service" is used to refer to a remote component (as is the case with web services today).
in the examples you are about to see, the pieces were trying to connect are simple classes, but they could be replaced with more complicated components, services, or objects. youll see me refer to some of these classes as services or even components, but in the end, they are just simple classes used within the example to make the point stick.
another term you will see is "bootstrap." this normally refers to a piece of code that connects various objects together prior to being used by the actual application or system.
finally, you should become familiar with the term "container" (a term that has been overloaded tenfold) as used in this context. here, were referring to an object that holds other objects. this can be a simple component or class, or something more complicated, such as a framework.
the problem domainin every application that you will ever have to build, there will be components that need to communicate with each other. for example, you might have to build a front end that communicates with the user and manages the presentation, navigation, and interaction. there may also be some middle-tier code that communicates with data stores, message services, or mainframes, and returns the retrieved data to the front-end code. furthermore, the back-end pieces that actually communicate with the above mentioned subsystems will also have to be built and connected to the rest of the system.
lets look at an example of this kind of programming in java. first, lets set the stage. imagine that we have a component named domainstore (which implements the domain store pattern). the purpose of this component is to abstract the caller, who wishes to persist some data to a persistent data store. keep in mind that our best practices dictate that the caller should not have to care where the final destination will be. the underlying datastore should utilize an appropriate implementation for storing or loading the data.
the actual underlying storage could be a local file, a database, or even a message queue. the point is that the caller shouldnt have to be concerned about what the underlying data store will be. in the real world, we all know that at some point, someone will have to decide what the actual data store will be, but this can either be chosen dynamically, or through a configuration file.
before we look at the domainstore implementation, lets first look at the interface that the domainstore will need to communicate with when attempting to pass data or read data from the underlying data store. the interface (as defined in listing 1) implements the data access object (or dao) pattern weve come to know and love by now. there are the usual create, read, update, and delete methods (crud, as its humbly come to be known as).
listing 1. the dataaccessobject interface definition
... 下一页