Controllers and Business Rules
Controllers and Business Rules
- Subject: Controllers and Business Rules
- From: Joseph Jones <email@hidden>
- Date: Tue, 28 Sep 2004 21:50:43 -0700
In the MVC setup prior to Cocoa bindings, Business rules enforcement was
done (or was recommended to be done in) the document. This held not only
your data but the rules behind access and modification of the data.
In the brave new world of Bindings, we have new classes that are used to
handle model modification (NSController and it's subclasses). Since the
controllers allow direct modification they seem to separate the Business
rule enforcement from the document but where does it go now?
My assumption is that the new way for enforcement to take place is to
subclass the appropriate controller you need and to insert your rules into
overrides of canAdd, canRemove, isEditable, etc. But this is only an
assumption and I have no way of knowing if this is correct or not, or good
or not.
Almost all examples and discussions deal with very simple examples that
don't seem to provide any explanation of rules enforcement in this brave new
world. While I think bindings are a great technology, without a means for
rules enforcement it seems limited in real world use.
If rules enforcement is still a part of the document then how do I get the
controllers to interact with the document? There doesn't seem to be an easy
way since there is no delegate mechanism in the controllers. I guess
bindings would work, but the only binding that seems to be surfaced is
isEditable, and it is woefully inadequate since it has no arguments or any
other way to tell who, what or how is requesting the editable state. Then
you have the fact that the controllers sidestep the document and operate on
the data directly that really complicates the matter.
Then again I could just be completely clueless here and in need of an
education (or RTFM links to the information I must have missed).
Thanx,
Joe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden