Separating WinForm from Logic

[Guest]

I have a WinForm class that has accumulated a tremendous amount of logic
code. Can anyone point me toward a good article on factoring logic code out
of a WinForm class?

Thanks,

 

[Guest]

Randy,

I don't know of any books that specifically deal with the subject, but the
pattern is relatively simple:

Take all the busy business logic out of the Windows Form class and put it in
a separate, reusable class that can be used by any form. The windows form
can reference an instance of the other class and make the method calls. If
appropriate, the methods in the class can be made static so an instance isn't
required.
Peter

 

[Greg Young]

For books specific to this .. I might recommend Applying Domain Driven
Design and Patterns by Jimmy Nilsson
http://www.amazon.com/exec/obidos/tg/detail/-/0321268202?v=glance (and some
related books Domain Driven Design and P of EAA (Fowler)

Cheers,

Greg Young

 

[Kevin Spencer]

It's pretty straight-forward. If code affects the User Interface directly,
such as changing the value in a text box, responding to a Click event or
other UI event, etc, it should be part of the code for the UI (form). If it
does not, it should be part of the business layer/classes. Now, where it
might get a little confusing is, for example, when an event handler does
something to a business object. Here, you want to use the event handler to
call a business method. In practice, it becomes only slightly more complex,
but that's the basic principle. Let your business layer do all the
manipulation of business data and enforcement of business rules. Let the UI
layer provide an interface between the User and the business classes/layer.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

This is, by definition, not that.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I have a WinForm class that has accumulated a tremendous amount of logic
code. Can anyone point me toward a good article on factoring logic code
out
of a WinForm class?

It depends of how the code was written, even if you have a lot of controls
and events handlers if the logic is implemented in separated methods it may
be simpler, ITOH if the logic is inside all the handlers (posibly the same
code in more than one handler) or a handler call to one or more other
handlers, then you have a real mess in your hands