我有一个 SearchService,它使用一种算法来查询数据库并返回结果。数据可以以多种不同的格式返回,具体取决于调用者想要从服务中获得什么。这些格式是:
- 直接与数据库中的表匹配的实体列表
- 匹配的记录的主键(长整型)列表
- “搜索结果”列表,由一组通常与以下内容相关的字段组成用户希望从搜索结果中看到什么(例如人名、地址、电话号码等)
目前我的 SearchService 如下所示:
public interface SearchService {
public List<People> searchPeopleReturnEntity(SearchRequest request);
public List<Long> searchPeopleReturnId(SearchRequest request);
public List<SearchResult> searchPeopleReturnSearchResult(SearchRequest request);
}
我正在寻找有关此方面最佳实践的建议。目前,命名约定似乎相当笨拙,我相信有比我现在更好的解决方案。
I have a SearchService
which uses an algorithm for querying a database and returing the results. There are a couple of different formats the data can be returned as, depending on what the invoker wants from the service. These formats are:
- A list of entities that directly match against a table in the database
- A list of primary keys (Longs) of the records that match
- A list of 'search results' which is composed of a bunch of fields that are generally relevant to what a user would want to see from a search result (say a persons name, address phone number etc)
Currently my SearchService looks like:
public interface SearchService {
public List<People> searchPeopleReturnEntity(SearchRequest request);
public List<Long> searchPeopleReturnId(SearchRequest request);
public List<SearchResult> searchPeopleReturnSearchResult(SearchRequest request);
}
I'm looking for advice on best practices regarding this. Currently the naming convention seems pretty clunky and I believe there is a better solution than what I have now.
发布评论
评论(6)
我将它们称为简单的名称,例如
getPeople
、getIds
、getSearchResults
。如果您需要对除人之外的实体使用这 3 个相同的方法,我会考虑制作一些通用的中间类型来定义它们,允许您编写如下内容:
I'd call them something simple like
getPeople
,getIds
,getSearchResults
.If you need these same 3 methods for entities other than people, I'd consider making some generic intermediate type defining them, allowing you to write something like this:
我将它们称为
findPeople()
、findPeopleIDs()
和findPeopleResults()
。I'd call them
findPeople()
,findPeopleIDs()
andfindPeopleResults()
.如果您的服务还可以返回其他实例(除了 People),我会将它们命名为
如果
SearchResult
仅用于人员,我还将其命名为PeopleSearchResult
。否则,我会给它一个通用参数,例如SearchResult
,然后List> getPeopleSearchResult()。
If your service can return other instances as well (besides People), I'd name them
If
SearchResult
is used for people only, I'd also name itPeopleSearchResult
. Otherwise I'd give it a generic parameter likeSearchResult<T>
and thenList<SearchResult<People>> getPeopleSearchResult()
.或者您可以使用
searchBy...
方法?尽管我同意这表示您将返回相同的结果。也许你可以重构一下:
因此你的 search... 方法总是返回 ID,然后您有专门的函数将它们转换为“正确的”搜索结果?
or you can use the
searchBy...
approach? though I agree that denotes you will return same results.Perhaps you can refactor a bit:
so your searc... methods always return ID's and then you have specialized functions to transform those into "proper" search results?
如果不是很明显,这种方法没有真正的“最佳实践”命名方案。
In case it isn't obvious, there is no real "best practice" naming scheme for this kind of method.
一种想法可能是:
然后您可以根据 resultClass 是 Person.class、Long.class 还是 SearchResult.class 返回不同的内容。
或者,不那么可怕的是,您可以这样做:
其中 ResultConverter 是一个接口,它接受某种原始搜索结果并返回合适的转换结果。您可以为常见的实例提供固定的实例:
One idea might be:
You can then return different things according to whether resultClass is Person.class, Long.class, or SearchResult.class.
Or, less horribly, you could do:
Where ResultConverter is an interface which takes some sort of raw search result and returns a suitable converted result. You could have canned instances for the common ones: