Towards Separating UI Code From All Other Code

[Jeff S]

Please note that this question is NOT about any particular pattern - but
about the general objective of separating out presentation logic from
everything else.

I'm trying to "get a grip" on some of the patterns (e.g., Model View
Presenter) or strategies for separating UI logic from the underlying
business rules and data.

As I understand it, the general intent of doing this is to reduce
dependencies amongst our classes in order to make the system more easily
extensible and maintainable. So in the case of Windows Forms applications,
we ultimately want a Form class that only deals with UI logic - while all
business logic is in some other independent class.

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?

For example, in the Model View Presenter (or Controller) pattern, where
would we instantiate the Model and Presenter (or Controller) classes? The
View is obviously the Form class - but where do we actually *instantiate*
everything else in order to maintain the independence we're trying to
achieve by breaking out these classes to begin with? My thought is that if
they get instantiated in the Form module, then the classes are not really
independent - given that the form class must know what object type to
instantiate.

What am I missing?

Thanks for your time and consideration.

[Jeff Louie]

I would take a different approach and say the main key is to separate
out the
application logic (Model) from the view and event handling code (View/
Controller). In MFC the Model is called the Document and everything else
goes
into what is called the View. In Unix the Model is called the ENGINE and
everything else goes into the INTERFACE. The simplest approach is to
consider
the Application as the Controller and this ApplicationController owns
the View
objects and Model object. Events are handled by the Controller that
updates and
queries the Model and then Updates the View.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jeff S]

Maybe I am too dense to understand how your response addresses my specific
question which was specifically about *where do we instantiate* runtime
objects when we're trying to achieve independence.

When you state the following...
<< the Application as the ApplicationController owns the View objects and
Model object. Events are handled by the Controller >>
You are apparently stating that "the Application" is were everything gets
instantiated. What is "The Application" specifically in the case of a
Windows Forms application? Is it the Main form's (SDI) or MDI Parent form's
class module? Is it the runtime instance of the main form that we consider
to be "The Application"? ... and therefore in the main Form's class that we
instantiate all the other objects? I understand there isn't one way to do
this...I'm just asking for ONE way that I can understand!

Really trying to understand this...

Thanks again.



"Jeff Louie" <je********@yahoo.com> wrote in message
news:eM**************@TK2MSFTNGP12.phx.gbl...

I would take a different approach and say the main key is to separate
out the
application logic (Model) from the view and event handling code (View/
Controller). In MFC the Model is called the Document and everything else
goes
into what is called the View. In Unix the Model is called the ENGINE and
everything else goes into the INTERFACE. The simplest approach is to
consider
the Application as the Controller and this ApplicationController owns
the View
objects and Model object. Events are handled by the Controller that
updates and
queries the Model and then Updates the View.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jeff Louie]

Jeff... if the the main application object owns the View and Model then
it is
using containment by ownership so that the View and Model objects are
created
or instantiated using the new key word in the main application object
source
code file eg. Form1.cs.

I have sample code here:

http://www.geocities.com/Jeff_Louie/OOP/oop3.htm

There is a link in there that lets you download the entire project.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Kunle Odutola]

"Jeff S" <[e-mail]> wrote in message
news:e5**************@TK2MSFTNGP11.phx.gbl...

Please note that this question is NOT about any particular pattern - but
about the general objective of separating out presentation logic from
everything else.

I'm trying to "get a grip" on some of the patterns (e.g., Model View
Presenter) or strategies for separating UI logic from the underlying
business rules and data.

As I understand it, the general intent of doing this is to reduce
dependencies amongst our classes in order to make the system more easily
extensible and maintainable. So in the case of Windows Forms applications,
we ultimately want a Form class that only deals with UI logic - while all
business logic is in some other independent class.

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?
In the class responsible for glueing the UI and the domain classes - the
controller. How is also an intersting question and the choice ranges from
direct instantiation to indirect instantiation (perhaps via dependency
injection using a container such as Spring.NET's, pico, Castle etc)
For example, in the Model View Presenter (or Controller) pattern, where
would we instantiate the Model and Presenter (or Controller) classes? The
View is obviously the Form class - but where do we actually *instantiate*
everything else in order to maintain the independence we're trying to
achieve by breaking out these classes to begin with? My thought is that if
they get instantiated in the Form module, then the classes are not really
independent - given that the form class must know what object type to
instantiate.

What am I missing?

Practical experience with simple but illustrative project(s). Have fun
playing with Spring.NET (or Castle) but, read Martin Fowler's piece on
dependency injection first I think.

Good luck.

Kunle

[Jeff S]

Thanks a bunch for the clarification. That helps, and it's as
straight-forward as I was suspecting it might be. I just read the Go4
Patterns book and some online stuff and NOWHERE did I see anyone talking
about specifically where these things get instantiated. I can understand the
concepts just fine and split the classes out - but when it's time to make
all hang together at runtime I got stuck. When it's presented independent of
actual code, then there is the illusion that these classes actually know
*noithing* about each other; but of course if that were really the case then
the app simply wouldn't work. The objects have to get instantiated
*somewhere* and it makes sense that it would be "at the application level" -
however that's done in the particular application type in question (Win
Forms, Web Forms, Console, etc.

Also thanks for the link. I'll be paying close attention.

-Jeff
"Jeff Louie" <je********@yahoo.com> wrote in message
news:e0*************@TK2MSFTNGP14.phx.gbl...

Jeff... if the the main application object owns the View and Model then
it is
using containment by ownership so that the View and Model objects are
created
or instantiated using the new key word in the main application object
source
code file eg. Form1.cs.

I have sample code here:

http://www.geocities.com/Jeff_Louie/OOP/oop3.htm

There is a link in there that lets you download the entire project.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Jeff S wrote:

<snip>

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?

This may well not apply to the situation you're in, but I've found that
an awful lot of the time, code can be made a lot simpler using a
pattern known as "dependency injection" (aka "inversion of control").
Here, instead of objects creating other objects directly, they are
usually provided their collaborators via properties (only knowing about
them as interfaces). In some cases, those collaborators may be
factories for other interfaces (eg you could have an IPersonQuery
interface which provides IPerson implementations when asked appropriate
questions).

You can then use a framework such as Spring.NET
(http://www.springframework.net) to "wire up" the application with
whatever implementation you require.

There's more information on this at the Spring.NET web site, amongst
other places. (I'm really still getting to grips with the whole thing
myself. I haven't needed to do much in the way of UI work, so it's hard
to know how much of it applies and how to the Model-View-Presenter
pattern.)

Jon

[Nick Hounsome]

"Jeff S" <[e-mail]> wrote in message
news:e5**************@TK2MSFTNGP11.phx.gbl...

Please note that this question is NOT about any particular pattern - but
about the general objective of separating out presentation logic from
everything else.

I'm trying to "get a grip" on some of the patterns (e.g., Model View
Presenter) or strategies for separating UI logic from the underlying
business rules and data.

As I understand it, the general intent of doing this is to reduce
dependencies amongst our classes in order to make the system more easily
extensible and maintainable. So in the case of Windows Forms applications,
we ultimately want a Form class that only deals with UI logic - while all
business logic is in some other independent class.

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?

By using reflection is entirely possible for there to be no code that knows
about anything other interfaces.

This is usually over idealistic and different approaches will be followed in
different circumstances. Putting the issue of interfaces aside:

1) The model should not depend on either the view or the controler since it
should be the least voltile part (in terms of code) and this is the main
motivation for the whole setup.
2) The controler must depend on both the model and the view since its whole
purpose is to mediate between them.
3) The view should not depend on the model because that would make the
controler redundant and it should not depend on the controler because that
would create a mutual dependency which would mean that there was no point in
separating view and controller.

These dependency "rules" imply that the only one of the three that could
directly instantiate the others would be the controler.

[Steve]

I've been looking at the MS Patterns and Practice groups "Composite UI
Application Block" (be prepared to spend a fair amount of time getting you
head around this!) - It is a complete framework that does exactly what you
want. It utilizes Observer, Factory, MVP / MVC, Builder, and other patterns
that are very common. So far I have been impressed and defeated, it's
powerful, but it's a major system to get used to. Also, prepare yourself
for a TON of classes, my god, there are so many classes. So far I have a
skeleton app with basic BOL/DAL layers in place and I'm over 20 classes.

It works though and it works well. Read more here:
http://www.gotdotnet.com/codegallery...a-f2eafbf2653c
and here:
http://msdn.microsoft.com/practices/...2/html/cab.asp

The samples are a little weak, they don't go deep enough for me, I still
have many questions. I would love to see this catch on though, It's real
powerful and if there were more people using it, I could have a better
chance of getting my 10+ questions answered ;0)

good luck.
"Jeff S" <[e-mail]> wrote in message
news:e5**************@TK2MSFTNGP11.phx.gbl...

Please note that this question is NOT about any particular pattern - but
about the general objective of separating out presentation logic from
everything else.

I'm trying to "get a grip" on some of the patterns (e.g., Model View
Presenter) or strategies for separating UI logic from the underlying
business rules and data.

As I understand it, the general intent of doing this is to reduce
dependencies amongst our classes in order to make the system more easily
extensible and maintainable. So in the case of Windows Forms applications,
we ultimately want a Form class that only deals with UI logic - while all
business logic is in some other independent class.

Specific Question: Where [do, should, can] we *instantiate* the non Form
classes in order to make them independent of the form on which its data is
being presented?

For example, in the Model View Presenter (or Controller) pattern, where
would we instantiate the Model and Presenter (or Controller) classes? The
View is obviously the Form class - but where do we actually *instantiate*
everything else in order to maintain the independence we're trying to
achieve by breaking out these classes to begin with? My thought is that if
they get instantiated in the Form module, then the classes are not really
independent - given that the form class must know what object type to
instantiate.

What am I missing?

Thanks for your time and consideration.