开云体育

Pragmatically, in the vast majority?of applications much less data is required for finding an entry than creating it.? Creating an entry with so much missing data can create data integrity problems.

So, given that findOrCreate() should need all the data that Create() would need (not just identifying information), I would find it cleaner to just allow Create to return the object whether it was created or already existed (and signal that the entry already existed if the client code cares).??

On Sun, Nov 24, 2019 at 1:55 AM J. B. Rainsberger <jbrains762@...> wrote:

Hi, folks. An old issue came back to the surface this month in consultation with clients and I'd like your opinion. It regards the old "find or create" pattern. It seems to violate Command/Query Separation (as I understand it), but it seems handy and harmless, so I'd like to find out more about what you folks think about it. Benign? Problematic?

I imagine using this with the Repository pattern. Let's say we register a patient in a medical environment and so we need a UI that reduces as much as possible the number of steps. We don't want to force the user to look up a patient just to discover that the hospital has no record of them, so we allow the user to enter some basic identifying information. This information suffices to either find an existing patient or create a new one if our database doesn't know that patient. The result is something like

Patient registeredPatient = patientRepository.findOrCreate(patientIdentifyingInformation);

The identifying information might have basics like name, date of birth, it doesn't matter. We can guarantee that registeredPatient now represents an Entity in our system, either because we found someone that matched the identifying information or because we created one.

This appears to violate CQS, but it seems like a good thing to have. Some individuals struggle with this, because they don't know whether this is an area where CQS "doesn't matter" or an area where CQS is trying to teach them something and they can't see what they're meant to learn. I haven't thought about this in depth in years, so I feel the same way right now. Drawbacks? Alternatives?

I was also thinking about how to design this, and it seems to me like a special case of getOrAbsent(), so that I could implement the generic findOrCreate() algorithm with something like

repository.find(identifyingInformation).orElse(T::createFromIdentifyingInformation)

where find() returns Maybe TIdentifyingInformation and T has a named constructor for creating a T from a TIdentifyingInformation. I'm assuming here that TIdentifyingInformation is enough to provide all the mandatory properties of T.

With this design, I don't need a single findOrCreate() function any more, because the pieces find() and orElse(T::create) communicate the idea well enough.

Thoughts? I'm happy to see the discussion meander. Is this a totally-solved issue and there's one clear good way to proceed? or is it more a matter of context or preference?
--

J. B. (Joe) Rainsberger :: :: ::