带有Neo4j的Spring,GraphRepository? vs手工界面 [英] Spring with Neo4j, GraphRepository<?> vs handmade interface

查看:277
本文介绍了带有Neo4j的Spring,GraphRepository? vs手工界面的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我发现有一个名为GraphRepository的接口.我有一个存储库,供用户实现可完成其工作的自制接口,但我想知道,是否应该实现GraphRepository?即使实施起来会很长并且某些方法将毫无用处,但我认为这是一个标准,并且我已经重新编码了此接口中定义的许多方法.

I found out that there is an interface called GraphRepository. I have a repository for users implementing a homemade interface that does its job, but I was wondering, shouldn't I implement GraphRepository instead ? Even if it will be quite long to implement and some methods will be useless, I think it is a standard and I already re-coded a lot of methods that are defined in this interface.

那么我应该编写"YAGNI"代码还是不遵守标准? 您有什么建议?

So should I write "YAGNI" code or not respect the standard ? What is your advice ?

推荐答案

您不需要实际实现GraphRepository而是对其进行扩展. Spring-Data的原理是(在启动时通过代理处理)所有的样板CRUD代码都已得到处理,因此您要做的就是为扩展GraphRepository的特定实体创建一个接口,然后仅添加您要使用的特定方法要求.

you don't need to actually implement GraphRepository but extend it. the principals of Spring-Data is that all the boiler-plate CRUD code is taken care of (by proxying at startup time) so all you have to do is create an interface for your specific entity extending GraphRepository and then add only specific methods that you require.

例如;如果我有一个实体CustomerNode,要创建标准的CRUD方法,我可以创建一个新的接口CustomerNodeRepository extends GraphRepository<CustomerNode,Long>. GraphRepository中的所有方法(例如save,findAll,findOne,delete,deleteAll等)现在都可以从CustomerNodeRepository访问并由Spring-Data-Neo4J实现,而无需编写一行实现代码.

for example; if i have an entity CustomerNode, to create standard CRUD methods, i can create a new interface CustomerNodeRepository extends GraphRepository<CustomerNode,Long>. all the methods from GraphRepository (e.g. save, findAll, findOne, delete, deleteAll, etc.) are now accessible from CustomerNodeRepository and implemented by Spring-Data-Neo4J without having to write a single line of implementation code.

该模式现在允许您处理特定的存储库代码(例如findByNameAndDateOfBirth),而不是简单的CRUD内容.

the pattern now allows you to work on your specific repository code (e.g. findByNameAndDateOfBirth) rather than the simple CRUD stuff.

Spring-Data软件包对于存储库交互非常有用.它可以减少大量的代码(代码行减少了80%以上),强烈建议您使用它

Spring-Data package is very useful for repository interaction. it can reduce huge amounts of code (have seen 80%+ reduction in code lines) and would highly recommend using it

实现自定义执行

如果要将自己的自定义行为添加到Repository方法中,则可以创建合并接口和自定义实现的概念.例如,假设我要创建一个名为findCustomerNodeBySomeStrangeCriteria的方法并执行此操作,实际上我想链接到关系数据库以执行该功能.

if you want to add your own custom behavior to a Repository method, you create the concept of merging interfaces and custom implementation. for example, lets say i want to create a method called findCustomerNodeBySomeStrangeCriteria and to do this, i actually want to link off to a relational database to perform the function.

首先,我们定义一个单独的独立接口,仅 包含我们的额外"方法.

first we define a separate, standalone interface that only includes our 'extra' method.

public interface CustomCustomerNodeRepository {
   List<CustomerNode> findCustomerNodeBySomeStrangeCriteria(Object strangeCriteria);
}

接下来,我们更新常规接口以不仅扩展GraphRepository,而且扩展新的自定义接口

next we update our normal interface to extend not only GraphRepository, but our new custom one too

public interface CustomerNodeRepository extends GraphRepository<CustomerNode,Long>, CustomCustomerNodeRepository {

}

最后一步是实际实现我们的findCustomerNodeBySomeStrangeCriteria方法

the last piece, is to actually implement our findCustomerNodeBySomeStrangeCriteria method

public class CustomerNodeRepositoryImpl implements CustomCustomerNodeRepository {

   public List<CustomerNode> findCustomerNodeBySomeStrangeCriteria(Object criteria) {
    //implementation code
}

}

因此,有几点要注意;

so, there's a couple of points to note;

  • 我们创建一个 separate 接口,以定义具有自定义实现的任何自定义方法(不同于与Spring-Data兼容的"findBy ..."方法)
  • 我们的CustomerNodeRepository接口(我们的主"接口)扩展了GraphRepository 我们的自定义"接口
  • 我们在仅实现 自定义界面的类中实现 only 自定义"方法
  • 默认情况下,自定义"实现类必须称为主"接口Impl,以供Spring Data拾取(因此在本例中为CustomNodeRepositoryImpl)
  • we create a separate interface to define any custom methods that have custom implementations (as distinct from Spring-Data compatible "findBy..." methods)
  • our CustomerNodeRepository interface (our 'main' interface) extends both the GraphRepository and our 'custom' one
  • we implement only the 'custom' method in a class that implements only the custom interface
  • the 'custom' implementation class must (by default) be called our 'main' interface Impl to be picked up by Spring Data (so in this case CustomNodeRepositoryImpl)

的幕后,Spring Data提供了CustomerNodeRepository的代理实现,作为自动构建的GraphRepository和我们的实现CustomCustomerNodeRepository的类的合并.该类名称的原因是允许Spring Data轻松/成功地将其拾取(此可以覆盖,因此它不需要* Impl)

under the covers, Spring Data delivers a proxy implementation of CustomerNodeRepository as a merge of the auto-built GraphRepository and our class implementing CustomCustomerNodeRepository. the reason for the name of the class is to allow Spring Data to pick it up easily/successfully (this can be overwritten so it doesn't look for *Impl)

这篇关于带有Neo4j的Spring,GraphRepository? vs手工界面的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆