In the previous article, we argued that a ComboBox is not enough.
Not because there is anything wrong with the control itself, but because the problem it is designed to solve is much smaller than the actual problem faced by a business application.
That, however, is where we stopped.
We did not answer the next question.
If the problem is not selecting a value, then what exactly is it?
Let us put frameworks aside for a moment.
Forget about controls.
Forget even the word Locator.
Imagine we are editing a line in a sales order.
The user moves to the product field and types:
PROD-001
What should happen next?
The first answer seems obvious.
"The product should be found."
Agreed.
But is that really enough?
Let us assume the product has been found.
Are we finished?
Not at all.
The application still does not know which sales price applies, which unit of measure should be used, which VAT rate is applicable, or even whether the item is currently available in stock.
And in many cases, it must know even more.
Perhaps a different pricing policy applies to this particular customer.
Perhaps a different price list is currently active.
Perhaps even the document date changes the result.
This leads to the first truly interesting question.
Where does all this information come from?
Suddenly, the product is no longer simply the product.
It is the same product within a specific business context.
And that context is not an implementation detail.
It is not an internal state maintained by whatever mechanism performs the resolution.
It is an explicit input to the problem itself.
There is another important observation.
The user did not enter a ProductId.
They did not enter a GUID.
In fact, they are probably unaware that such an identifier even exists.
They entered:
PROD-001
In other words, they entered a business reference.
This is perfectly natural.
People do not think in terms of technical identifiers.
They think in product codes.
Names.
Barcodes.
Account numbers.
Concepts that carry meaning within the business itself.
That is their language.
The information system, however, operates differently.
Its relationships rely on unique, stable identities.
Primary keys.
GUIDs.
Surrogate keys.
Someone must therefore translate the language of the user into the language of the system.
And that translation must be correct.
Within the appropriate business context.
Up to this point, one could argue that we are simply describing a search.
I would probably agree.
At least until the first real business scenario appears.
Because a search merely returns results.
Here, however, we are not simply searching.
We are trying to answer a much more specific question.
Which business entity does the user actually mean?
That is a fundamentally different question.
It is not about discovering information.
It is about resolving a business reference.
Let us now give names to the individual steps of this process.
The user provides a business reference.
The application evaluates it within the current business context.
It attempts to resolve it.
It arrives at a canonical business identity.
Finally, it returns the information required for the task to continue.
Conceptually, the process looks like this:
Business Reference
│
▼
Business Context
│
▼
Resolution
│
▼
Canonical Identity
│
▼
Projection
Notice something interesting.
There is no ComboBox.
No Grid.
No Dialog.
In fact, there is no user interface at all.
There is only a process.
That process does not always produce the same outcome.
It may find no matching entity.
It may find exactly one.
It may find a small number of possible candidates.
Or it may find so many that the result is no longer useful.
The last case deserves special attention.
If the system returns five products, we are dealing with normal business ambiguity.
The user can easily choose the correct one.
If, however, it returns five thousand products, we are no longer dealing with ambiguity.
We are dealing with a business reference that is simply too broad to be resolved.
The problem is not the list.
The problem is the reference itself.
The application should not ask the user to choose one product out of five thousand.
It should ask for a better business reference.
This distinction is fundamental.
Business ambiguity and resolution failure are not the same thing.
The more closely we examine this process, the harder it becomes to view it as just another UI control.
The same process can be used by a desktop application.
A web application.
A service.
A data import process.
An automated workflow.
The interaction changes.
The resolution process does not.
And when the same concept appears in exactly the same form regardless of the application type or user interface, it stops looking like a UI detail and starts looking like an architectural concept.
Perhaps this is the real meaning of the word Locator.
Not as a control.
Not as a search mechanism.
But as the name of an architectural concept.
A concept with one—and only one—purpose:
To transform human business references into canonical business identities within a specific business context.
This is what, in this article, we call The Locator Pattern.
If the Locator is indeed an architectural pattern, another question immediately follows.
How should it be described?
What is the minimum information required to define a Locator?
How can that description remain independent of the mechanism that executes it?
In other words,
Can a Locator be defined declaratively?
That is precisely what we will examine in the next article.
Fundamental Concepts of Business Applications III: Locator Definitions
Closing Question
Does this concept already exist, perhaps under a different name, in the framework or platform you use?
If so, I would genuinely like to learn about it.
Top comments (0)