Re: EOF and the Observer Pattern
Re: EOF and the Observer Pattern
- Subject: Re: EOF and the Observer Pattern
- From: Chuck Hill <email@hidden>
- Date: Fri, 31 Oct 2008 11:52:33 -0700
On Oct 31, 2008, at 4:46 AM, David Avendasora wrote:
On Oct 30, 2008, at 4:46 PM, Chuck Hill wrote:
Hi David,
On Oct 30, 2008, at 2:44 AM, David Avendasora wrote:
I have several places in my application where a large number of
EOs exist in the DB that are directly dependent upon other EOs. If
the depended-upon EOs change, then all the dependent EOs may need
to be updated.
Are these all guaranteed to be in memory at the same time? Do you
run multiple application instances?
Well... Multiple Apps (JC & Web) accessing the same DB via a common
foundation framework. But only one instance of each application.
So what is the plan for syncing this information between the two when
one changes it after both have fetched it? Is the data re-fetched
frequently enough?
This seems to me like the perfect use of the Observer Pattern.
Or not. It sounds more like Publish - Subscribe. Or is that the
same...?
Yep. Same thing.
Sometimes. There might be another pattern that I am thinking of, or
this is a variation. With the original / orthodox Publish -
Subscribe, the Publisher (Subject) knows who the subscribers are.
Using NSNotificationCenter is more like one of those free weekly
newspapers: the publisher does not know who the subscribers are and
the subscribers can choose to not receive it (with a sign on their
front door).
For example. If a Part's BOM is updated the nutrition information
for that Part may need to be updated as well. Calculating the
current nutrition information is too expensive to do it everywhere
it is needed so it is saved in the database. I also maintain
historical nutritional information as well and that shouldn't be
updated, only the current information should be.
What I'd like to do is to have the "current" Nutrition object
observe the Part object.
Or have the part broadcast a NSNotification when it is modified.
Then any other objects can choose to subscribe to this notification
if they deem it interesting.
This sounds exactly like what I want. I figured there had to be a WO-
way of doing this.
If the Part object is updated in a significant way, then the
Nutrition object will get notified to update itself.
Publish - Subscribe gives a bit more decoupling between the change
and the response.
I guess the key is that the Part will not know what is significant
to the subscribers. Some subscribers could potentially ignore some
notifications. Is this possible?
Yes. The notification can contain an object. I'd suggest the Part's
GID, not the Part EO, unless these will be handled within one EC.
Which might be what you want. I am not really sure that notifications
are what you want. You really want the EOs in _one_ EC updated and
saved and then for EOF to sych the data in the other ECs. I think....
But back to your question. The notification can contain an object,
some representation of the part. The objects receiving the
notification can use some method is isMyPart(partFromNotification) to
determine if they care or not. If not, just carry on.
What I'm trying to figure out is how to persist this information.
I don't think I want to model the relationship, do I?
I don't know. It is your model. What is it you are thinking of
persisting?
What subscribers a publishing object has and vise-versa. This isn't
a per-ec thing, it should be remembered across sessions.
That is the beauty of this, there is no need to have this coupling.
I looked at EOObserving but I think that's more about catching
changes between two objects already in memory.
How would I model EOEnterpriseObject <<->> EOEnterpriseObject
anyway? Using EOIDs?
Now, I think I am lost.
Never-mind that last part. It was me trying to do things the hard way.
You?!!? Really?!!?
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden