M
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.
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.