UI Plumbing in Business object

barski

Junior Contributor
Joined
Apr 7, 2002
Messages
240
Location
Tennessee
first a little background. over the past year i have slowly been trying to move toward an oop thought on each new project i get. so my understanding isn't complete newbie but pretty far away from what i would call intermediate skills.


my question

how do things like implementing custom editors or ibindinglist on business objects\collections which i do for sole purpose of making it easier for the ui to interact with the business object. On it's face this would seem to breaking some rules but the business object doesn't need to know anything about the ui\presentation it just proving some nice "plumbing". Therefore, to me it's ok not much different than providing a business object event that will more than likely only be used by the ui.

any thoughts on this would be appreciated.
 
When I find myself adding extras to the business logic to make it easier for my UI I sit back and ask myself, "What would happen if the UI changed?" So, if I'm targeting Windows Forms, would this potential enhancement still be useful if I created a command line interface that used the same business logic? What if I moved everything to a website?

Some presentation-useful stuff is essential and appropriate in a business class, for example GetShortName(). The short name in and of itself might not be super useful to the internals of your class, but by allowing an object to determine it's own short name you maintain higher cohesion and keep the business knowledge associated with the class.

As an example, let’s say you have a GUI requirement where no two items in a listbox can have the same name. What if two different objects return the same short name? One option is to have the object fix the problem. The other and better option (in my opinion) is to ensure the requirement is remedied in your UI. So, you retrieve the short name, increment it if necessary, and concatenate to make a new short name.... short, otherShort, short(2), short(3).
 
thanks for the input. i can't disagree because i am moving Gui things into business objects. it just seems to me implenting something like ibindinglist for a collection that allows the collection bind in an "expected" manner or a custom editor that would allow the object to bind to property grid "effectively" isn't so bad and if the gui changes nothing breaks it just may no longer serve a purpose. Having said all that it still is gui in the business object......

I really do appreciate your input. maybe a couple more years i'll get this figured out.
 
Back
Top