Monday, December 15, 2003, 2:19:35 AM, Niclas Hedhman wrote:
> On Monday 15 December 2003 06:25, Daniel Dekany wrote:
[snip]
>> (Here I would like to note that, IMO it would be better if "release
>> requirement" is bounds to the Role, and not the Service.)
>
> To the ROLE??? (A bit outside my territory as I don't like the whole Role
> concept at all :o) )
[snip]
> public interface MyReleaseRequirement
> {
> void release();
> }
>
> public interface MyService extends MyReleaseRequirement
> {
> // whatever
> }
[snip]
I think this approach has some disadvantages (compared to what I have
suggested):
- When the "release requirement" bound to the Role, you can use
components of whatever lifestyle for that role, not only of lifestyle
that actually need "release requirement". This gives better separation
for implementation details. By declaring the Role as "has release
requirement", you say that for this role you potentially want to use
components that use on of these evil performance-optimized lifestyles,
but you can still use any component implementations there. You have just
allowed some extra lifestyles, such as "pooled", on the expense that you
will try{...}finally{release}.
- The service interface is polluted with this implementation-detail
stuff, release(). First of all, it is ugly, since releasing has perhaps
nothing to do with the service semantic (*). And then, it is
possible that for the same service (interface), multiple implementations
exist, and some of them uses lifestyle where "release requirement"
wouldn't be needed at all.
* Releasing and service semantic:
I understand that often releasing is connected with the semantic of the
service, as in the case of a DatabaseConnection service, but it is not
always the case. For example, I have a Web app framework, where the
high-level (application level) processing of HTTP requests is done be
Components. As these Components usually contain application specific MVC
control code, that you want to write and modify quickly and simply,
use-once-and-discard lifestyle is practical for them, which requires
explicit releasing. Explicit releasing is not a problem here, since
these Components can be requested and called by the Web app. framework
core only, so using "release requirement" for all HTTP request
processing Roles is just a single try{...}finally{release} in the Web
app framework code, and does not introduce any addition complexity in
the user code. So with no expense, it allows the usage of any fancy
lifestyles for the request processor Components. And, of course,
releasing has nothing to do with service provided be these Roles, which
looks like this:
interface Processor
{
/**
* Processes the HTTP request, and usually changes the page object
* based on that.
*/
void process( Environment env, Request req, Page page )
throws Exception;
}
--
Best regards,
Daniel Dekany
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
