On Sun, 2002-11-24 at 01:15, Leo Simons wrote: > Services don't go into the Context > ---------------------------------- > This is something very important to stress. Services should not go into > the context. If it is something a component acts upon actively and > contains some business logic for, it probably isn't a component and can > go into the context. If not, it is probably a service which you should > handle through ServiceManager. > > example: a home directory where a component is allowed to interact with > the filesystem is something to put into the context, whereas a storage > service with which a component can interact to store data is not. > > I tend to try to use context as little as possible (in the above > example, you'll see me always using the storage service rather than the > context entry).
actually, this is a bad (because incomplete) example. What should usually happen if you ask me: 1) you figure out your components need permanent filesystem-like data storage 2) you use the StorageService component from the component repository and add it to your assembly spec 3) StorageService gets a home directory from the container through the mechanism described to handle the data storage (you could also provide it with an URI in the Configuration) 4) your application components that need storage declare a dependency on and get a reference to the StorageService this is basically the Separation of Concerns pattern applied, separating out "filesystem interaction" into its own entity. note: things can become more complex if you are working with a very dynamic runtime component setup (not in this example, but in the general case). cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
