Quarkus Panache Active Record vs. Repository Pattern

[@jhirn2957]

As someone coming from Rails back to Java after 12 years, Quarkus is a refreshing find. Repository pattern is absolutely ridiculous to me. Entities are inherently tied to a data store so letting them find and persist themselves is not a violation of the often overrated Single Responsibility Pattern. How things are persisted IS domain knowledge. You get more for less with AR pattern and less is always easier to change should the persistence change.

[@Liwgfr1]

Thank you, Sebastian! Very inspiring and valuable tutorial. Would like to suggest you making something with EventBus / Reactive Messaging with Quarkus with SSE (Server-Sent Events) usage. In my opinion, really interesting topic, but there are not enough guides with this stuff. Thanks again!

[@zrubiz]

Thanks for the video. I use the active record pattern because to me it make much more sense then the repository pattern and there is also 1 more benefit to the active record that you didnt mention: If you need to use multiple entities in one place you won't need to inject each and every one of them, just use the object as is which less code that is more orginzed.

[@SebastianDaschnerIT]

Good point about the multiple entities. In my projects that's very often a hierarchy of entities with relations that are loaded by JPA. But yes, that can save you some code.

[@omar-zahid]

I use Active Record pattern. If I'm not mistaken this approach is preferable by the Quarkus team over the repository pattern but your argument makes me want to migrate over to the repository.

[@skpatel20]

I was favoring the repository pattern until I read "If I'm not mistaken this approach is preferable by the Quarkus team over the repository pattern." Interesting. Any references?

[@Maruf-zt7dz]

i am from an another language where everyone praised ActiveRecord but it actually sucks to me after moving to repository

[@DanielWamara]

I always use the Active Record pattern because using the Repository pattern will mean for me 2xn classes if I have n entities and I always go for as less classes as I can.

[@SebastianDaschnerIT]

Fair point :)

[@vemaiesli1121]

It seems to me like using Active record pattern breaks Single Responsibilty Pattern because we're having both database responsibility and entity responsibility in a single Entity class. Or am I missing something here?

[@SebastianDaschnerIT]

Yes, and I'd agree

[@wenijinew]

Hi Sebastian, Thanks for the video. Could you please share which applications do you use to record and edit the video?

[@SebastianDaschnerIT]

Sure, OBS on a second computer, see blog.sebastian-daschner.com/entries/chroma-keying-video-setup for programs & equipment

[@SebastianDaschnerIT]

For editing I used to use anything that works straightforward (I mostly only cut), I used shotcut; now I have a video editor who supports

[@juanantoniojimeneztorres7386]

I prefer Active Record way, But this is a static way. In the TDD you must use a "panache mock". But this way I think is more clear. repository way is another "a long time ago" layer.

[@SebastianDaschnerIT]

Yes, but that an approach has been around for a longer time is not necessarily negative, right? ;) Why is it that you prefer the Active Record way? Because the testing you mentioned is in fact rather a reason against it :)

[@juanantoniojimeneztorres7386]

@@SebastianDaschnerIT You're right. But I prefer it because in this way there are less classes than if I use repository pattern. Also, I think it's better to have the entity definition and its data access methods together. It's cleaner. In tests, I rarely mock entities. Since I do TDD, the tests start out being collaborative, and only at the end, when I have refactored over and over again, and the code is finished, is when I do the isolated unit tests, and then I no longer care if the test crosses the line. data layer and ends up persisting. In this case, I think H2 and testContainers are your friends.

[@marcodelpercio]

I've read the tutorial of Panache a long time ago and I use Quarkus in production...the problem with both approaches is that it only shows how to deal with very very trivial examples where you basically run SELECT * from a single table...yeah it's cool but it's not realistic...in the real world of large databases queries are complex, joining 3-4 tables and very rarely doing SELECT *...very often queries extract only a small subset of fields or maybe fields from different entities joined or even calculated fields like aggregation....How do you do that with Panache repository/active-record? If the answer is JPQL or Criteria query ...hell no... it's just way easier and efficient to write an SQL query.

[@SebastianDaschnerIT]

You're absolutely right that most real-world apps have more complex queries than just SELECT *. For this, the Panach repository approach is actually perfect, since it naturally encapsulates the domain-specific queries into that separate class. It's possible to use either native(SQL)/named/JPQL or criteria queries, that's up to you :)

[@marcodelpercio]

@@SebastianDaschnerIT thanks for your reply. I would be very interested in seeing Panache in use for a real world query with something that is not SELECT * from a single entity. If you make a video on that I'll be the 1st to watch. So far I've been using native queries and JPA ResultSet mapping pretty much everywhere except those very rare cases where I need to do a SELECT * from a single entity.

[@bmasetto]

Awesome video!!! Is there a way to use records instead of classes in the panache active approach?

[@SebastianDaschnerIT]

Quarkus Panache does work with records (I've done a video on this here: blog.sebastian-daschner.com/entries/java-records-quarkus-enterprise ), but I claim that for entities, records doen't really make sense, rather for value object that might be realized as JPA embeddables.

[@gargarism]

One thing that always bothered me is that for example "var coffee = Coffee.findById(id);" would not really work - you'd have to use "var coffee = Coffee.findById(id);" to get the correct type for your coffee variable.

[@SebastianDaschnerIT]

Oh yes, good point