Peter Duniho said:
IMHO, you should wait for clarification from the person who suggested that
in the first place.
well, that's kinder than Jeff's idea
I believe that the crux of the issue is a failure to use precise meanings
for terms like "reference". Without clarification of the original
suggestion, it's not going to be possible to know exactly what the right
thing to do in VS is.
I will also take this opportunity to caution you against taking anything
you read, here or elsewhere, as the final truth.
yeah, that's my default MO. Though until someone or my own experience
shows something to be wrong, i have no basis for what to accept/reject.
For example, I note in
the MVC/MVP discussion it was suggested that the presenter/controller
object should know about the specific UI controls. However, while it's
true that when one is being lax about the division of labor, the
presenter/controller often has specific knowledge about the view object
(and indeed, may be the same object), that would not be true when using
MVC or MVP in their purest forms.
i was a little surprised about that too.
Instead, the view would expose some UI-agnostic interface used by the
presenter, encapsulating all of the actual UI-specific control types, etc.
and hiding them from any other class. To do otherwise ties the non-UI
code to a specific UI implementation.
that's what I thought it would look like
can you give me a hint what that would look like in my case,
if i have a form with a DataGridView
I have a presenter which has gotten some data from a 'business object'
i'm picturing something like
IUI_Interface
private void DisplayData(<type> data) ;
(not sure what type to use to make it theoretically agnostic to my current
app? i assume object?)
in theory, in future projects, maybe data will come in as a string, or a
List<string> or collection or ???
in my case, in the instance i'm thinking of, i will have a List<string> I
want to display..
but an interface wants to be as generic as possible, right?
then in the actual form
private void DisplayData(object? data)
{//current implementation
...cast data to List<string>
...put list into datagridview
etc}
then in the presenter
ConcreteForm.DisplayData(this.data);
???somethign like that???
One of the major values of following a true MVC/MVP design is that you can
replace your view with anything you like without requiring changes to the
other elements. If you start with a view that exposes .NET Forms types to
the controller (for example), then changing the UI to be based on WPF,
web-based, console-based, etc. becomes very problematic, because none of
those view implementations would naturally have any Forms types at all.
exactly. And for what I'm trying to do this is getting way more complicated
than it needs to be...however, due to a significant defect in my character
<g>
I want to learn the "right/best" way to do things, even though I have no
economic
justification for all the time i'm spending trying to learn all this which
is so far
above my head....
Anyway, that's a long way of saying that you should take everything with a
grain of salt. Start with some fundamental design goals, and then take a
moment to evaluate any advice against those goals. It's pragmatic to be
flexible about what goals one is addressing and how, sacrificing purity of
design for practicality. But make sure you do so consciously, rather than
just taking at face value everything you read.
Pete
I very much appreciate everyone's help that i receive here, and of course
on my own have little to go on in terms of corroborating/evaluating the
validity
of some of it...Thats' why I so appreciate the different voices that can
come in
and address any specifics that I may be getting confused on due to my lack
of knowing.
Thanks
mark
