proper programming? (events)

[giddy]

hi ,

ok , i have a programming background but i'm new to C# . i'm also self
taught so :

i have a datagridview that should act differently depending on which
user has signed in

now is it more effecient/correct if i do this:

if(user=="user1 ") {
this.dataGridVi ew2.CellBeginEd it += new
System.Windows. Forms.DataGridV iewCellCancelEv entHandler(this .dataGridView2_ CellBeginEdit_U ser1);
}else {
this.dataGridVi ew2.CellBeginEd it += new
System.Windows. Forms.DataGridV iewCellCancelEv entHandler(this .dataGridView2_ CellBeginEdit_U ser2);
}

as opposed to check for which user in ONE cellBegin event??

Thanks
Gideon

[Dave Sexton]

Hi,

<snip>

>>At a certain point a form goes beyond these simple UI object / business
object interactions. Decisions about UI state become more complicated. UI
controls need to react to the events raised by the use of other UI
controls. UI controls may be disabled if the user does not have
authorization , if the business object is read only, if a particular tab is
not selected etc. This is when I use a separate object. The code behind
remains simple and the form once again returns to simple UI control /
object interaction, e.g. this.deleteEmpl oyeeButton.Enab led =
myObject.Empl oyeeDeletionAll owed;

I agree, but in this example you still only need to set an Enabled
property. That could be done using simple property-binding.

Yes, but the logic required to work out if the button should be enabled is
something that should be encapsulated outside of the code behind in it's own
object. I guess I use the Mediator pattern.

"Define an object that encapsulates how a set of objects interact. Mediator
promotes loose coupling by keeping objects from referring to each other
explicitly, and it lets you vary their interaction independently"

Yes, we're on the same page here as well.

The mediator pattern is interesting. Here's some more information I found on
the subject in the context of an article on the Message Broker Pattern [link
after sig]:

"Mediator [Gamma95]. The Mediator pattern separates objects so that they are
only aware of the mediator but not each other. The Broker deals with similar
concerns, but it can only be used in the context of enterprise applications."

So your example does seem like the mediator pattern. And if the actual type
of "myObject" was the "UserUICapabili ties" class from my original response,
that would make even more sense. It would just need a property named,
"EmployeeDeleti onAllowed". Since it was created by a User object, it would
act as the mediator between the User and the UI.

<snip>

Thanks for the discussion.

--
Dave Sexton

"Message Broker Pattern"
http://msdn.microsoft.com/library/de...sagebroker.asp

[giddy]

Hi Dave ,

i didnt see your post before posting my second reply! i hit the reply
button , went to have lunch! and wrote my post only in response to Toms
post! lol and i did'nt have time to replay back! sorry....

yes , your approach makes whole lot of sense , i did'nt even give a
thought to making seperate classes! infact i've decided to seperate a
lot more .. .thanks

although the complexity at which i'm working is not much. Each user has
about 5 levels of privileges..... basically i thought it would be more
effecient to register an event with the right delegate in the first
place(when the form loads) so i would'nt have to go checking INSIDE the
function (when the event fires) , for what privilege the user has!
anyway i think the object method is more effecient! and a lot more
cleaner... .

thanks again!

Gideon