Abstraction Layer for Lucene Java

Nov 9, 2010 at 7:23 PM
Edited Nov 9, 2010 at 7:26 PM

What do you think about an abstraction layer for Lucene(core can be Lucene.Net or IKVM translated Lucene Java)?  It can either be a wrapper with .Net taste(like Linq to Lucene) or a search service(for ex.) similar to Solr. This abstraction layer can even make use of Lucene Java if necessary.

Or all of them at once?

DIGY

Coordinator
Nov 11, 2010 at 9:10 AM

Digy,

You hit the nail on the head, for sure. I think an abstraction layer will be key to implementing this project. 

My thoughts are that we should define all of the domain constructs as interfaces along with any constants or enumerations in a project called "definitions" (there is a lucere.definitions project for this specific purpose). This will allow for many different kinds of flexibility... On one hand, it means we could have multiple different implementations all co-existing. So, yes, we could start by wrapping Lucene.Net or Java Lucene on IKVM, and later replace it with a different implementation. It also allows for better unit testing with mocks and more flexible injection of customized end-user implementations into the system.  It also allows for better decoupling strategies which means more potential for distributing work.

Java Lucene and Lucene.Net current handle abstraction using abstract base classes instead of interfaces. The support for this is a bit spotty... Not everything can be inherited from or has a public constructor. I think we should keep the idea of abstract base classes there but use them for what they are meant to do -- reuse and manage common implementation details for subclasses.

Thanks,

Troy