I don't really see this as much of a problem. You mostly just need to "trust" 3rd party libraries (such as XWork) to do the job correctly -- so you can just assume the container will always work. As long as you've done some integration testing, the resource (Connection) will never _not_ be passed in during production, so there is no need to worry about NPEs at that point.
-Pat ----- Original Message ----- From: "Rob Rudin" <[EMAIL PROTECTED]> To: "Rickard Öberg" <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 10:22 AM Subject: Re: [OS-webwork] IoC Mini Tutorial [Was: ParameterAware deprecation] > I think one drawback can be that you have to do some extra null- > checking. In the case of a connection, the class probably has a > private instance of Connection, and when it needs to use the > Connection, it might not have a guarantee that the Connection > is not null - i.e. that setConnection has been called. If the > class actively creates its Connection, then it doesn't have to > worry about nulls. Of course, it then has to worry about > database errors that might occur in getting the Connection, > which it doesn't have to worry about in the IoC approach. > > Rob > > > > ---- On Thu, 06 Mar 2003, =?ISO-8859-1?Q?Rickard_=D6berg?= > ([EMAIL PROTECTED]) wrote: > > > Patrick Lightbody wrote: > > > Even more, services can depend on other services, so you > can create very > > > large resource dependencies such that each resource is > small by itself, but > > > can be used to form large building blocks. XWork examines > the dependency > > > graph and correclty loads resources in the correct order > using a simple > > > depth-first search on the graph. Even more, the container > can be used > > > outside of XWork and applied in other situations, such as > OSWorkflow. In my > > > application at Cisco, I've got FunctionProviders (an OSWF > thing) that > > > implement the same Aware interfaces that my Actions do, and > both get access > > > to the same resource. > > > > > > OK, did that sell anyone? The end result is SUPER > simplified code that is > > > much better suited for unit testing (think: > > > action.setConnection(mockConnection)) and only focuses on > requirements and > > > doesn't worry about any "glue", since the container handles > all that. > > > > What are the drawbacks of this approach? > > > > /Rickard > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Etnus, makers of > TotalView, The debugger > > for complex code. Debugging C/C++ programs can leave you > feeling lost and > > disoriented. TotalView can help you find your way. Available > on major UNIX > > and Linux platforms. Try it free. www.etnus.com > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony- > webwork > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger > for complex code. Debugging C/C++ programs can leave you feeling lost and > disoriented. TotalView can help you find your way. Available on major UNIX > and Linux platforms. Try it free. www.etnus.com > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
