There is nothing wrong with a view knowing how to display an object - in
fact making it 'agnostic' when there is nothing agnostic about it is an
anti-pattern. If you did find things that were common across more than one
entity its a simple matter of abstracting that out into a base control
later. Although make sure that you don't start doing things inside the view
that should infact be done by the object ie.. making decisions based on the
view state as opposed to the object state, also don't reconstruct the object
from the control, you cannot assume that an object state can be represented
completely by what's shown in the view (for existing data) for new data the
view simply returns a new instance of the object constructed by user input..
cheers.. vivek
On 10/15/06, Jan Limpens <[EMAIL PROTECTED]> wrote:
Hello,
I have a more ore or less complicated business object, that looks
similar to this:
<Entry>
has some properties (id, pubdate...)
and a list of <Version>s
each <Version> has a language, a title and a description and a list of
<Image>s
each <Image>, has a List of <ImageInfo>s with Title and Description
To edit the objects properties I created a similar structure of controls
<EntryControl> has some Textboxes and a Tabstrip, holdig Tabs
corresponding to <Version>s, again holding some Textboxes a list of
<ImagesControl>s with their <ImageInfoControl>s.
The question is, should the control A) know of the business object it
represents?
Should I instantiate EntryControl like this?
Entry e = EntryFactory.GetEntry("abc");
EntryControl ec = new EntryControl(e);
and "inside" of EntryControl my Properties would be
public string Id {
get { return entry.Id; }
set {
entry Id = value;
TextBoxId.Text = value;
}
}
and have problems, once the user edits the fields, a call to Id, would
still yield the object's value and not the textbox' new text value.
But I'd have the advantage (still in Entry) that I could much better
encapsulate the child controls creation and logic.
public EntryControl(Entry entry) {
versionControl.Versions = entry.Versions // now I can encapsulate
// everything onwards in
// VersionControl
}
or B) should my Controls be completely agnostic containers of agnostic
sub controls
Instead:
class EntryControl {
private Textbox textBoxId, textBoxPubDate;
public string Id {
get {return textBoxId.Text; }
set {textBoxId.Text = value; }
}
public VersionControl VersionControl;
}
class Client {
void DoSomething() {
Entry e = Entry.GetEntry("abc");
EntryControl ec = new EntryControl;
ec.Id = e.Id;
ec.VersionControl = new VersionControl();
foreach(Version v in e.Versions) {
VersionTab tab = new VersionTab(); // this will be difficult to
// read back later. What
if the
// user inserts a new version
// in the middle...?
tab.Title = v.Title;
}
}
}
What is your opinion? What is the best pattern in relation business
objects vs controls.
To me it seems version A encapsulates better, is easier to read and is
more comfortable to use. But concurrency makes it less attractive;
B has the advantage of dumb controls that cannot do anything wrong,
but writing the client code is an ugly hack.
Any beautiful patterns?
--
Jan
www.limpens.com
===================================
This list is hosted by DevelopMentor(r) http://www.develop.com
View archives and manage your subscription(s) at
http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
