I am currently on the decision, whether to use interfaces throughout my whole spring project or not. I scouted some open source projects and saw, that many big projects are handling that quite heterogenously. All the big sample Spring apps aren't really doing that, although I thought that this would quite improve maintanability. Her for example project sagan: https://github.com/RameshMF/sagan/tree/master/sagan-common/src/main/java/sagan/blog

However I saw quite a lot big open source projects, that strictly do that, for example Broadleaf commerce: https://github.com/BroadleafCommerce/BroadleafCommerce/tree/develop-6.0.x/core/broadleaf-framework/src/main/java/org/broadleafcommerce/core/order/domain

I am a bit insecure what architecture to choose and I am a bit confused about the pros and cons in general, could you help me out a bit?

  • As a quick answer, refer to the YAGNI principle. You've noticed that it's not a common idiom, so it's probably not essential for your architecture. – Kayaman Aug 21 '19 at 8:43
  • Well, I already had quite some work with refactoring and bugfixing and I think that future debugging/refactoring would benefit from that. – Tom Aug 21 '19 at 9:23
  • If you think it will help you in the future, go for it. I don't really see the point of an additional abstraction layer there. In fact I'd say this makes it a bit too easy to pass entities around, instead of using dtos/domain objects. Would have to study the architecture of that project to see how it uses them, but I've never made interfaces for entities, and I doubt I'll start now. – Kayaman Aug 21 '19 at 9:42
  • Do you see any reason why they did that in the broadleaf project than? I am very curious, because I did see that idiom actually a couple of times already, for example in liferay project too. – Tom Aug 21 '19 at 9:45

Disclaimer: These assumptions are based on a quick glance at the codebase

It looks as if the interfaces are used as a "disguise" for entities to be directly used as domain objects / dtos. This does have a small advantage in that instead of passing around a raw entity, you pass around the interface. However you end up having to write an interface for every entity, and you're still passing around entities even if they're disguised. The interfaces even have setters, so it doesn't protect the entity from misuse.

So instead of interfaces? Convert your entities to domain objects. You still have a layer of abstraction, but instead of empty interfaces you have nice domain objects that you can put business logic into. Prefer an anemic domain model? You could map the entities to dtos, with services containing the business logic for them. This isn't far from the interface approach, but it allows for more leeway as the dto isn't tied directly to the entity like the interface is.

But as software development is half engineering and half art, the entity/interface approach might be great in the Broadleaf project. Unless you understand and intend to implement the same architecture in your project, it doesn't make sense to do it unless you can justify it to yourself.

Apparently this design has been discussed a lot long time ago https://lostechies.com/jamesgregory/2009/05/09/entity-interface-anti-pattern/

And looks like some fool has answered a somewhat related issue (where the interface is a bit different) on SO: https://stackoverflow.com/questions/27183825/should-the-entity-class-implements-interface

Also related https://stackoverflow.com/questions/18109547/orm-entities-vs-domain-entities-under-entity-framework-6-0

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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