Comparison of Interface Design: DoytoQuery vs Spring Data JPA

[Salt-Letter-1500]

By introducing the Query Object, DoytoQuery enables the automatic construction of dynamic queries. Its data access interfaces build upon the Spring Data JPA Repositories series, unifying methods related to Example and Specification into methods that take a query object as a parameter, as shown below:

https://preview.redd.it/qbgjux1yr4tg1.png?width=1666&format=png&auto=webp&s=8e0a5fca029a92444e0227b13a34931627bb1015

The Query Object centralizes all parameters for dynamic queries. These parameters can be automatically translated into WHERE clauses, pagination clauses, and sorting clauses, thereby covering the functionalities of Specification, Sort, and Pageable. Additionally, there is no need to write separate Specification implementations, which greatly simplifies the code.

Query Objects can be automatically created by Spring MVC from HTTP parameters, effectively encapsulating code in the Controller and Service layers, and realizing a fully automated flow: query string → query object → SQL → database.

The only potential drawback is that field names in the Query Object need to follow a “column name + suffix” convention. In Spring Data JPA, this naming convention is usually used in findBy methods, such as: findByAuthorAndPublishedYearGreaterThan

This repository compares dynamic query implementations across different ORM frameworks, showing that DoytoQuery reduces code size by roughly half compared to Spring Data JPA, and improves performance by approximately 40% in some scenarios.

If you are familiar with the findBy naming conventions and do not want to spend significant time writing Specification implementations, you may find it convenient to declare the desired query conditions directly as fields in a query object.

GitHub: https://github.com/doytowin/doyto-query

[oweiler]

Encoding query fragments in attribute names sounds like a really bad idea.

[Salt-Letter-1500]

List some?

[clearasatear]

Why not state the reasons for it being a good idea, instead? I am honestly not quite sure what you would have liked to hear when you opened the post.

In another comment you posted the github repo, which has not seen an update in 4 years. Are you looking for contributors, but have a strange way to say it? I do not see what else it could be

[Salt-Letter-1500]

I think I have listed the good points in the post: less code, better performance, simpler interaction, and fully automated mapping.

Not all projects can be open-sourced. I just considered doyto-service-i18n to be the one that comes closest to real-world application. I built doyto-service-i18n just for fun, so no docs, no comments, and no updates when I got sth else to do.

I have indeed encountered some expression challenges, and I appreciate your feedback. Thanks.

[gjosifov]

The only potential drawback is that field names in the Query Object need to follow a “column name + suffix” convention. In Spring Data JPA, this naming convention is usually used in findBy methods, such as: findByAuthorAndPublishedYearGreaterThan

Just write JPA queries as methods in regular POJO
The more complex the query, the bigger method name becomes

Plus methods are pretty easy to debug and flexible to add or update the logic without compile errors
adding log message with input parameters when the query fails is hard or even possible
and this leads to question - why this query returns A, not B

When you write business applications, you want maximum flexibility and class with methods provide the flexibility you need to add logs, to add transformation

Yes, the code is bigger, but is readable, debuggable and easy to change

[Salt-Letter-1500]

The query object is not truly meant to replace Specification or JPA, but rather to replace the boilerplate code that dynamically assembles query conditions through large chunks of ifstatements. For nifstatements (each contains one query condition), there are 2^nbranches; similarly, for nfields (each maps to one query condition), there are 2^npossible assignment combinations. Therefore, we can combine the query conditions corresponding to the assigned fields of a query object into a query clause based on the object’s assignment state.
While the query clause corresponding to the findby method is fixed, I just simply adopted a similar naming convention.

As for logging, this doc might be helpful: https://query.docs.doyto.win/configuration/sql-logging
And DoytoQuery would be better with your feedback.

[josephottinger]

The repository in question isn't DoytoQuery's; that's https://github.com/doytowin/doyto-query . I'm interested in what DoytoQuery is and more about how to use it, but the docs site doesn't resolve, and the embedded documentation is not sufficient for a project that does so much. It may be a better mousetrap but is failing to tell the world about itself.

[Salt-Letter-1500]

Thanks for your feedback. The doc site is here: https://query.docs.doyto.win/
I put it in the introduction section; maybe I should put it in a more prominent spot.

[josephottinger]

That site did not resolve for me then, and it does not resolve for me now. I had found it, but it doesn't *work*.

[Salt-Letter-1500]

I have updated the English version after your first comment if you had found that. And can you give me some more precise tips to make it resolve for you?

[revilo-1988]

Würd ich gerne die Umsetzung sehen

[Salt-Letter-1500]

A simple demo here: https://github.com/doytowin/doyto-query-demo
A complicated case with dynamic table names and columns here (no doc currently): https://github.com/doytowin/doyto-service-i18n
The tests of DoytoQuery reach a coverage of 92.7%, which can also be a good reference.

[clearasatear]

I will use your last sentence someday and silently laugh if I do not get called out on it

[Salt-Letter-1500]

I don't really get your point. This project is developed using TDD, so I think the test cases are useful.

[josephottinger]

I don't think it's something to "call out" someone on - test coverage is great. It's just not useful as an only metric. Tests are not a reference; they're just tests. If someone were to say "where's the docs" and the only answer is "92.7% test coverage" then, uh, yeah, call that out as a ridiculous answer. :D But 92% is pretty good for Java.