Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have an interface to communicate with a DB (actually it is not a database, but this is to give a concrete example):

interface DbInterface{
    Result sendQuery(Query q);
}

And I am trying to improve reusability by separating specific components into individual projects:

  • App1, an application that requires access to a database
  • App2, an application that requires access to a database
  • DB1, a concrete implementation of DbInterface (let's say SQL)
  • DB2, a concrete implementation of DbInterface (let's say using some NoSql database)

How do you typically design such an architecture and where should DbInterface be located?

  • in one of the applications? but that means all other three component depend on that project to access the interface - does not sound right
  • in one of the DB implementations? same - does not sound right.
  • in both DB implementations? code duplication.
  • in a separate project, which would only contain that interface? seems abusive to include a dependency for one interface only.

For reference, this is Java + maven, but the issue is fairly generic I suppose.

share|improve this question
    
As three people have already given you the right answer, I will write mine in a comment: a separate project. And that separate project is called X-API where X is whatever you want to call it. Remember that an API, event when it only has interfaces is a project nonetheless. –  user61852 Sep 4 '13 at 20:29

3 Answers 3

up vote 6 down vote accepted

The interfaces are what you use to define a contract between the Applications and the implementation. That contract is usually managed by a middle project referred to as the API or SDK.

The application uses interfaces from the SDK, and the DB1 project implements those interfaces, but it's the SDK project that defines those interfaces.

enter image description here

share|improve this answer

I would personally go with the separate project. Pretty much every project I have worked on has had some kind of 'common' project/library that all others reference.

While it probably is overkill just for a single interface, it seems likely that there might similar cases in the future, and when that happens you already have a dedicated place to put them.

I don't know the ins and outs of your applications, but are there no helper classes etc that might be of benefit to both projects that could also go in a common project?

share|improve this answer
    
So a sort of company-toolbox project that contains the pieces that are typially reused. Not a bad idea. –  assylias Sep 4 '13 at 15:12
    
This solution models JDBC type mentality, with JDBC being a common interface shared among applications (part of the JVM), and individual jar library files which implement each database type. Maybe this isn't Java, but I think this is an excellent approach regardless. –  Neil Sep 4 '13 at 15:39

A separate project would be best in this scenario. Though now it will contain just a single interface, it may grow. Normally this type of project is called something like "API". There is no reason that a project such as this cannot contain some logic (for example, if you wanted to provide a facade on disparate API interfaces), but it should not be implementation specific.

Most applications should only have to rely on this API project as you should be coding to interfaces anyway. Only projects which tie in some sort of specific implementation will actually have to know about the API implementations. In modern applications that extensively use DI, the implementation is usually just a runtime concern.

Examples abound in the Java realm. JPA and Apache Commons Logging (or any other logging API) are a couple that you have probably already worked with.

As far as your comment "seems abusive to include a dependency for one interface only". I can see how this feels a bit awkward the first time you encounter it, but I would argue that it is more abusive to include dependencies you don't need in a project as you would be doing if you had to include the implementation to get only the interface.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.