7 Replies - 885 Views - Last Post: 23 March 2014 - 03:28 PM Rate Topic: ***** 1 Votes

#1 andrewsw   User is offline

  • blow up my boots
  • member icon

Reputation: 6544
  • View blog
  • Posts: 26,532
  • Joined: 12-December 12

MVC guidance on approach

Posted 22 March 2014 - 06:42 PM

I am planning to adapt my MVP tutorial to the MVC pattern. I have struggled to find good examples but the two I am currently looking at are:

c-sharpcorner
codeproject

The first looks excellent (I think!?) and I can follow it and make use of it. It doesn't have any custom events, just method-calls.

The second is not entirely clear (and I even have one or two question marks about it) but I think it could still be useful to me. It uses a number of custom events.

  • Which approach follows the MVC pattern more closely, events or methods?
  • If the answer is both then what will help me decide which is more appropriate for a particular change?

[The GoF use the term 'notifies..' suggesting events, wikipedia uses the term 'commands' suggesting methods.]

If you have the patience ;) I have another question which is more specific:

I will be using the TextChanged event of textboxes to cause (or request) updating of the model. If the update cannot happen I'll probably paint the background of the textbox. I can use individual methods to do this; that is, a method for each textbox/field. This is probably an accurate reflection of the pattern(?) but how could I create a single method of the view that would update the corresponding textbox?

The problem as I see it is that we are no longer (unlike MVP) using properties of the form/view to correspond to those of the model. I cannot, that is to say, I shouldn't!, pass a control-reference to a method of the controller (and back to the view).

Or perhaps I shouldn't attempt this as it would break the pattern?

Is This A Good Question/Topic? 1
  • +

Replies To: MVC guidance on approach

#2 click_here   User is offline

  • D.I.C Regular

Reputation: 46
  • View blog
  • Posts: 300
  • Joined: 25-November 13

Re: MVC guidance on approach

Posted 22 March 2014 - 07:13 PM

I have recently gone though all this and the conclusion which I reached is that it is best to use events and interfaces.

That way you can change the View to anything, and as long as it has the same interface, the other parts of the code won't notice.

[edit]
The main link that convinced me was this:
http://www.dreaminco...ny-other-forms/

I know that it is not directly written about the MVC pattern. However, I concluded that an event based approach (as explained in the tutorial) would better because of the same reasons that it is better when communicating accross 2 forms.

[/edit]

This post has been edited by click_here: 22 March 2014 - 07:37 PM

Was This Post Helpful? 0
  • +
  • -

#3 andrewsw   User is offline

  • blow up my boots
  • member icon

Reputation: 6544
  • View blog
  • Posts: 26,532
  • Joined: 12-December 12

Re: MVC guidance on approach

Posted 23 March 2014 - 03:09 AM

Thank you.

View Postclick_here, on 23 March 2014 - 02:13 AM, said:

That way you can change the View to anything, and as long as it has the same interface, the other parts of the code won't notice.

You can add an event to an interface, but also methods, so I still don't see where one would be preferred over the other.

I can see the advantage, and need for, events in a larger application. For example, the data-model could fire change-events when the data is changed by something outside of the application. (In fact, it might be interesting to simulate this using a Timer.)

Any other thoughts are welcome ;)
Was This Post Helpful? 0
  • +
  • -

#4 click_here   User is offline

  • D.I.C Regular

Reputation: 46
  • View blog
  • Posts: 300
  • Joined: 25-November 13

Re: MVC guidance on approach

Posted 23 March 2014 - 05:02 AM

If you [say] hit a button on your View, do you want your View to call a method on your Controller, or do you want the Controller to react to an event raised by the View?

Consider the option of the View raising an event: The View does not depend on the Controller at all -> This is good, because it removes dependence from other sections of the code, and other classes can react to the button push without the View having to deal with it. The View only has to worry about what is presented to the user, not any of the workings of the operation (i.e. It does not have to worry about which method is being called).

Now consider the View calling a method from the controller. Now the controller needs to be known in the View; probably in the constructor. The View is now dependent on having the Controller when being run, and the View is now controlling when the method is called.
Was This Post Helpful? 0
  • +
  • -

#5 andrewsw   User is offline

  • blow up my boots
  • member icon

Reputation: 6544
  • View blog
  • Posts: 26,532
  • Joined: 12-December 12

Re: MVC guidance on approach

Posted 23 March 2014 - 05:51 AM

View Postclick_here, on 23 March 2014 - 12:02 PM, said:

..The View is now dependent on having the Controller when being run,

It would be anyway wouldn't it? You cannot run or test the view independently of a controller, or a fašade-controller that implements the controller's interface.

Quote

and the View is now controlling when the method is called.

To my understanding I think it is more accurate to say that the View requests change through the Control (and the Control can then update the View).

To my understanding none of these objects can be, or are intended to be, autonomous. It is the interfaces that create the separation of concerns. Each can, however, be tested separately by creating fake-objects that implement the interfaces. Importantly, the view (in my initial case, a Form) can be removed and another presentation layer be inserted. To this extent the application and business logic is considered independent of the presentation layer.

I am open to correction ;)
Was This Post Helpful? 0
  • +
  • -

#6 click_here   User is offline

  • D.I.C Regular

Reputation: 46
  • View blog
  • Posts: 300
  • Joined: 25-November 13

Re: MVC guidance on approach

Posted 23 March 2014 - 03:01 PM

Quote

View requests change through the Control


I still see this as the View controlling the Control.
Was This Post Helpful? 0
  • +
  • -

#7 click_here   User is offline

  • D.I.C Regular

Reputation: 46
  • View blog
  • Posts: 300
  • Joined: 25-November 13

Re: MVC guidance on approach

Posted 23 March 2014 - 03:09 PM

I have chosen the Event way of doing things because I felt that it seporated the two classes better.

I don't think that I can convince you of the same thing, so I think that I'll pass the "talking-stick" on!
Was This Post Helpful? 1
  • +
  • -

#8 andrewsw   User is offline

  • blow up my boots
  • member icon

Reputation: 6544
  • View blog
  • Posts: 26,532
  • Joined: 12-December 12

Re: MVC guidance on approach

Posted 23 March 2014 - 03:28 PM

Thank you click_here.

I found an interesting related article:

Using Events to decouple View Models

I will continue to pursue this ;). As long as choosing to use methods or events (or probably a combination of these) doesn't break the MVC pattern then I don't have to fall on one side.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1