Question on Asynchronous Query

When the user clicks on a row in the MemberListView screen, I get the selectedItem and pass it to my model. In my model for the detailscreen, I Fetch the individual member selected and .Include his/her job histories, dues records. In the callback completed method I loop through the job histories and add them to a ObservableCollection Jobs. This displays them in the grid on the member form. That works fine. What doesn't work is that in my Domain Model class for JobHistory I have the following to display the Employer Name

Bindings work by adding an event handler to the INotifyPropertyChanged event of any object they want to monitor.
In your case this event may be firing against the Employer object, but your EmployerName property is on a different object, so you will have to raise the NotifyPropertyChanged for the JobHistory object yourself.
I often do this by intercepting the Setter of the Employer object, add an event handler programatically that checks for parameter "EmployerName" on the nested object being changed, and in turn raise the change event for "EmployerName" in the JobHistory object.
It works the second time because the object is already updated, so your interface is not reacting to the RaisePropertyChanged, but to the fact it is reading values for its initial bind.
This is always an issue when you have properties reading values from nested objects, and it becomes your responsibility to relay the change events, as it's clearly impractical for the system to bubble property change events up entire trees, and .NET has no awareness of the dependency a property definition has on any code implementation it contains.

These issues have been present in every aspect of .NET's property event handling, but has become far more high-profile as lazy loading with UI level binding in Silverlight and WPF has become more common.  In the past we would often see cases of people 'rebinding' or 'refreshing' their screens to reflect changes to these nested objects, rather than addressing the real issue that you have found.

Cheers,
 Jason

Without  sample app it's a bit tricky, but from what I can see...

foreach (JobHistory jh in Member.JobHistories)

{

Jobs.Add(jh);

}

OnPropertyChanged("Jobs");

if Jobs is an ObservableCollection then you don't need to raise the PropertyChanged.
basically, it looks like you need to have something like this in the EmplSite setter:

this.EmplSite.Employer.PropertyChanged
                    += delegate(object sender, PropertyChangedEventArgs o)
                                    { if (o.PropertyName == "EmployerName") RaisePropertyChanged("EmployerName"); };

I think this will check for the contents of the nested object being changed, and reflect that change in your top level object.

You have to remember that your collection doesn't change when the objects are async received from the database, as DF is simply replacing an object into an existing one, not adding or removing objects from the collection.

Also, why do you have a Jobs collection? This is the same as Member.JobHistories so you can bind straight to that collection.

In fact, you could bypass this whole problem by binding to Member.EmplSite.Employer.EmployerName in your XAML code, so unless you have a good reason for replicating the property to the top object I would do it this way.