Live data from Hacker News

Opinion: Stop Using the Generic Repository Pattern

goodjava.org

1–2 of 2 posts

Re: Opinion: Stop Using the Generic Repository Pattern

#2
This is a good presentation of issues I have had with so many Dao classes in the past. The point about "updates" always taking in a full object is probably the biggest problem I have with the generic approach.

Thinking on it, I'm curious if this is also why I don't see as many null pointer exceptions. I much prefer making the methods I plan on having at each layer only get passed information that should exist. Same with what they pass back. I'd imagine a codebase that uses the original pattern is full of objects that are not fully filled out. (And moving to optional doesn't really help in these cases. Since you don't know why it is missing. You could move to either or some larger lazy load mechanism, but all of that feels like way more code. And that will be more bugs.)

For the proposed replacement, I would recommend not designing an interface that requires a back and forth. Such that, the "business" logic should also not have to check against retirement age before calling retire. That said, I could see reasons to still have the various methods. (Especially since this one is not "per employee.")