Search for a consistent set of rules for Models and Views in C#

[mswlogo]

We frequently keep running into the same set of inconsistent practices
around models and views and would like some other opinions.

1) There is no such thing as a "Controller " in C#. Developers keep
creating them, but in the purist sense they can't exist in C#. The View
and Controller are always one.

2) Exposing the internal structure of the Model to pass its contents to
something else (often another model) is bad. Let's say the model's
internal data structure is an ArrayList (for now). Developers often
will add a property to get this array list out. I argue that you should
add an interface to the Model to get the "Elements" of that ArrayList.
This way if you extend the model you just extend that interface and you
maintain appropriate access to the model rather than some
representation of its internals. It also avoids the whole issue of
returning a reference to the internal versus copying it. Passing a
reference to the ArrayList doesn't scale well as the model develops.

3) Who owns the model? Does the View Own the Model? If so when the View
is destroyed and something wants access to the data in the Model it's
kinda gone. If the Object that created the View is also responsible for
creating the Model this seems to break the encapsulation.

4) Can the Model ever directly reference a View? This gets messy. If we
create a Dialog (that we decide is simple enough that requires no
model) is it legitimate for the Model to call the Dialog. But then we
run into window ownership issues, since the model has no "Window"
and the Dialog wants a parent window. I think it's pretty clear that
the model should not directly reference any of it's "own" views
and only do that through subscribed events.

5) The Busy loop. This is how it usually goes. We add an update event
and any time the model changes we fire it. Then things start to get
complicated and we introduce a BegingUpdate/EndUpdate set of methods
(these control if update events should be fired or not). Then a bunch
of code evolves some using BeginUpdate/EndUpdate and some not. An valid
argument one developer keeps saying is, don't have the UpdateEvent
and then we don't need te BeginUpdate/EndUpdate and the let users of
the model explicitly call FireEvents().

6) Visual Studio Dialog Designer. This thing just seems to get in the
way. It discourages Model/View design and you have to go very out of
your way (and it's way) to have a Model/View based window. There are
many threads that discuss the issue is also the .Net WinForm library is
just poor plain poorly designed.

[john conwell]

Right...because as we all know, the ONLY way to design a UI is with the MVC.
Thats why FMC was such a raving hit!!!

whats your point?

"mswlogo" wrote:

We frequently keep running into the same set of inconsistent practices
around models and views and would like some other opinions.

1) There is no such thing as a "Controller " in C#. Developers keep
creating them, but in the purist sense they can't exist in C#. The View
and Controller are always one.

2) Exposing the internal structure of the Model to pass its contents to
something else (often another model) is bad. Let's say the model's
internal data structure is an ArrayList (for now). Developers often
will add a property to get this array list out. I argue that you should
add an interface to the Model to get the "Elements" of that ArrayList.
This way if you extend the model you just extend that interface and you
maintain appropriate access to the model rather than some
representation of its internals. It also avoids the whole issue of
returning a reference to the internal versus copying it. Passing a
reference to the ArrayList doesn't scale well as the model develops.

3) Who owns the model? Does the View Own the Model? If so when the View
is destroyed and something wants access to the data in the Model it's
kinda gone. If the Object that created the View is also responsible for
creating the Model this seems to break the encapsulation.

4) Can the Model ever directly reference a View? This gets messy. If we
create a Dialog (that we decide is simple enough that requires no
model) is it legitimate for the Model to call the Dialog. But then we
run into window ownership issues, since the model has no "Window"
and the Dialog wants a parent window. I think it's pretty clear that
the model should not directly reference any of it's "own" views
and only do that through subscribed events.

5) The Busy loop. This is how it usually goes. We add an update event
and any time the model changes we fire it. Then things start to get
complicated and we introduce a BegingUpdate/EndUpdate set of methods
(these control if update events should be fired or not). Then a bunch
of code evolves some using BeginUpdate/EndUpdate and some not. An valid
argument one developer keeps saying is, don't have the UpdateEvent
and then we don't need te BeginUpdate/EndUpdate and the let users of
the model explicitly call FireEvents().

6) Visual Studio Dialog Designer. This thing just seems to get in the
way. It discourages Model/View design and you have to go very out of
your way (and it's way) to have a Model/View based window. There are
many threads that discuss the issue is also the .Net WinForm library is
just poor plain poorly designed.

[Joanna Carter \(TeamB\)]

"mswlogo" <ms*****@hotmai l.com> a écrit dans le message de news:
11************* *********@g43g2 00...legr oups.com...

1) There is no such thing as a "Controller " in C#. Developers keep
creating them, but in the purist sense they can't exist in C#. The View
and Controller are always one.
We have designed our own MVP (Model View Presenter) framework in Delphi and
are porting it to C# with no problems at all.

The Presenter (Controller) is definitely a viable separate entity and we are
even thinking of making it a RAD component.
2) Exposing the internal structure of the Model to pass its contents to
something else (often another model) is bad. Let's say the model's
internal data structure is an ArrayList (for now). Developers often
will add a property to get this array list out. I argue that you should
add an interface to the Model to get the "Elements" of that ArrayList.
This way if you extend the model you just extend that interface and you
maintain appropriate access to the model rather than some
representation of its internals. It also avoids the whole issue of
returning a reference to the internal versus copying it. Passing a
reference to the ArrayList doesn't scale well as the model develops.
IMO the Model should contain a "Value" which is the real business object.
The Value contains any properties and methods that pertain purely to
behaviour the business object alone. But if there is behaviour that affects
objects related to the Value type, then that behaviour should be a part of
the Model class.
3) Who owns the model? Does the View Own the Model? If so when the View
is destroyed and something wants access to the data in the Model it's
kinda gone. If the Object that created the View is also responsible for
creating the Model this seems to break the encapsulation.
The Presenter (Controller) can own the Model but it is not necessary that
any one class does so. It is the job of the Presenter to either create or
link to a View.

Your application code will usually create an instance of a business class
and then pass that to the constructor of the Presenter; in essence this can
be said to be "presenting the business object".

The Presenter then creates an appropriate Model and passes the BO to its
constructor so that it then becomes the Value of the Model. Nothing takes
ownership of the BO, it is "owned" by the app code that created the
Presenter.

The Presenter also is responsible for creating a View if a whole object is
being edited and a form is required; but it only links the View to the
Value/Model in the case of an edit displaying a property of of an object.
4) Can the Model ever directly reference a View? This gets messy. If we
create a Dialog (that we decide is simple enough that requires no
model) is it legitimate for the Model to call the Dialog. But then we
run into window ownership issues, since the model has no "Window"
and the Dialog wants a parent window. I think it's pretty clear that
the model should not directly reference any of it's "own" views
and only do that through subscribed events.
The Model/Value should never know anything about the UI that is used to
display/interact with it. As I have said the Presenter is the class that
owns both the Model and the View in the case of a form, but only the Model
in the case of an edit control.

You should be using the Observer pattern to link the View to the Model. I
use Interactors to react to the events of the View and translate those
"gestures" into Commands on the Model.
5) The Busy loop. This is how it usually goes. We add an update event
and any time the model changes we fire it. Then things start to get
complicated and we introduce a BegingUpdate/EndUpdate set of methods
(these control if update events should be fired or not). Then a bunch
of code evolves some using BeginUpdate/EndUpdate and some not. An valid
argument one developer keeps saying is, don't have the UpdateEvent
and then we don't need te BeginUpdate/EndUpdate and the let users of
the model explicitly call FireEvents().
The Model and/or the Value should be the Subject in the Observer pattern and
the View should be attached to this Subject. In MVP, the Interactors that
respond to events from the View can be enabled or disabled to avoid any
circular reactions to updates from the Model triggering further reactions in
the Model.

Begin/EndUpdate are useful if several changes in data should be reflected in
the UI to avoid flickering.
6) Visual Studio Dialog Designer. This thing just seems to get in the
way. It discourages Model/View design and you have to go very out of
your way (and it's way) to have a Model/View based window. There are
many threads that discuss the issue is also the .Net WinForm library is
just poor plain poorly designed.

We use the form/dialog designers in Delphi and C# to layout forms and set
the names of controls to equate to the names of the properties that they are
to display. The Presenter links up the edits to the properties when it
creates one sub-presenter for each property.

We have not created a designer for use in the IDE but it is something in the
pipeline and looks to fairly easy to implement. AFAICS, the designer should
represent/edit the Presenter and should take the form of a design surface
that creates non-visual classes.

There are some articles about MVP using Delphi on my website :
www.carterconsulting.org.uk

Joanna

--
Joanna Carter
Consultant Software Engineer