I have a situation where I have a BusinessBase object for Employee. After the user enters the Employee's full address (address, city, state, zip), I want to check to make sure there is not a duplicate record already in the system for that address. I then want to show the duplicate records to the user so they can check them. Should that occur in the UI or can it happen in the business object? I was thinking it could be a check in the BO that gets fired after each field gets Set. It would check to make sure all of the fields have been entered before it hits the database to look for the duplicate. However, I don't know how to notify the UI that records exist and they need to be shown? Thanks.
You might consider exposing an event on your business object that you would fire if duplicates were detected. Then, you would have an event handler within your user interface to respond when that even is raised.
As far as potential duplicates, it's certainly an option that you could have a collection on your business object that holds the results of your command object duplicate check (assume that's how you're doing it) and have that be a collection you make publicly available (potentially as a reference you supply in a beefed up event args for the event you'd expose).
Another option would be to make your user interface code invoke the check for duplicates and simply provide the underlying business objects to do a duplicate check in the database based on address, city, state, zip.
Apart from the implementation, address matching is tough to do in any system. The variations in an address are so great that some extremely fuzzy logic needs to be used to identify "matches" based on address. "123 N. Elm St" may or may not be the same as "123 North Elm Street #42". Maybe the first address didn't have the number on it. Maybe they are different. Hard to tell.
My question would be why? Why do you care if the address is in the system? For data normalization? This "duplicate" data is really not a big deal. The most important thing is that an Employee's address not be linked to someone else's address that happens to be similar. Then a change to one means a change to the other.
Address matching is indeed complex. Totally agree with you.
If you approach addresses the same way many do, they are their own root object - not just arbitrary child data on an individual or organization. Addresses in our system are modal objects - 5512 2nd Avenue represents an object with it's own particular qualities and potentially history - if I lived there and moved, I wouldn't actually change the address itself - rather, I would point myself to another address.
So it is in part a normalization issue - yes. And in our case, duplicate data isn't desirable.
To get really good at this, you might pair your application with something like MelissaData, and use delivery point validation to essentially get a perfectly unique value for an address that is entered/corrected/and recognized.
Writing your own logic to match addresses, like Wbmstrmjb says, is anything but easy.
Thank you for your help. I like the idea of exposing the event from the BO and then capturing it in the WinForm.
Our address check is not that complicated. It is just to let the user know there may be another Employee in the system with a similar address. I appreciate the ideas though. Thanks.
Copyright (c) Marimer LLC