Binding Business Objects to Controls (or not)
-
Hello, I have a more ore or less complicated business object, that looks similar to this: has some properties (id, pubdate...) and a list of s each has a language, a title and a description Entry also has a list of s each , has a List of s with language, title and description To edit the objects properties I created a similar structure of controls has some Textboxes, a Tabstrip, holdig Tabs corresponding to s, again holding some Textboxes, and a list of s with their s. The question is, should the control A) know of the business object it represents? Should I instantiate EntryControl like this? Entry e = Entry.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 versionControl = new VersionControl(); 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 (as the generic .net controls are) 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(); // will be difficult to // reconstruct e later. What // if the user inserts a new version // in the middle...? tab.Title = v.Title; ec.VersionControl.Tabs.Add(tab); } // ... } }What is your opinion? What -
Hello, I have a more ore or less complicated business object, that looks similar to this: has some properties (id, pubdate...) and a list of s each has a language, a title and a description Entry also has a list of s each , has a List of s with language, title and description To edit the objects properties I created a similar structure of controls has some Textboxes, a Tabstrip, holdig Tabs corresponding to s, again holding some Textboxes, and a list of s with their s. The question is, should the control A) know of the business object it represents? Should I instantiate EntryControl like this? Entry e = Entry.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 versionControl = new VersionControl(); 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 (as the generic .net controls are) 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(); // will be difficult to // reconstruct e later. What // if the user inserts a new version // in the middle...? tab.Title = v.Title; ec.VersionControl.Tabs.Add(tab); } // ... } }What is your opinion? WhatA - the business object layer shouldn't know anything of how the data will be presented.
If you're stuck in a rut: 1) Consult the documentation* 2) Google it 3) Ask a sensible question 4) Try an ancient ritualistic knowledge summoning (:badger::badger::badger:) dance :jig: 5) Phone :bob: * - If the documentation is MSDN > 6.0 then forget it!
-
A - the business object layer shouldn't know anything of how the data will be presented.
If you're stuck in a rut: 1) Consult the documentation* 2) Google it 3) Ask a sensible question 4) Try an ancient ritualistic knowledge summoning (:badger::badger::badger:) dance :jig: 5) Phone :bob: * - If the documentation is MSDN > 6.0 then forget it!
Neither in A or B the businesslayer has any knowledge of it's representation (in my examples)