Re: [hibernate-dev] Usage of the Service pattern in Hibernate Search
For me its a matter of consistency. Put simply a Service comes from a
ServiceRegistry. That's consistent. This idea that some particular
Service might come from here or there or this other place is not
consistent. To me.
Now, I understand that there is likely a performance impact to this (Map
lookup) which I assume is likely more the driver of this question. But I
prefer the consistency/readability when the performance is
equal/negligible. However, were the performance impact big, obviously that
changes things.
That's my take and my means of weighing this for ORM.
On Thu, Mar 19, 2015 at 8:13 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Looks like the ServiceRegistry pattern is getting quite popular in
Hibernate Search.
There are three default implementations (of three services) which are
provided by the hibernate-search-engine itself.
Essentially the hibernate-search-engine code looks it up, and loads
from its very same jar; I'm finding this a bit weird.
Wouldn't it make more sense to actually look up for the service only
for alternative (non-default) implementations?
We don't have a strategy to pick one implementation if there are
multiple implementations around (other than throwing an exception), so
having a service defined in the engine jar, essentially means noone
can plug an alternative, unless he overrides the
SearchConfiguration#getProvidedServices() method.
So if the intention was to allow choice, something is missing. If not,
I'd rather load the default implementations explicitly (via their
traditional constructor).
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev