Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Which design to use?  RSS feed

 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to determine to correct pattern to use in the re-engineering of
a current swing application. This application accesses a socket to retrieve
information from a unix box. The socket is accessed every 10 seconds via a timer to gather the most current information and refresh the data on the screen. I was thinking that the MVC pattern to be a good choice for this with the timer residing in the controller, which would access the socket in the model to gather the latest data, then refresh the data in the view? Is this a good choice or are there others that would work better.
Thanks,
Barry
 
Joe Nguyen
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you have control over the application on unix box? If you do, I would recomend using the pushing model instead of the pulling model. Instead of periodically pulling data to refresh the screen, let the application on unix box notifies your controller when something happens. This is the observer pattern.
 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That would probably work except that the application on the unix box retrieves new information every 3 seconds. We've been told that we can't be accessing the socket that often because of network traffic. Therefore, the
swing app is set to refresh every 10 seconds.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When using MVC, your timer would sit in the model, not the controller. The controller's responsibility is to handle user input. Your timer is part of your application logic and shouldn't need to change when the form of user interaction is changed.
 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I can see the timer in the model to re-capture the data from the socket but how does the controller know when to refresh to view with the current information?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think one could argue for the timer in the controller. Refreshing at some interval might be an "application" decision rather than a universal "model" feature. My emotional investment: 50/50. It's up to you to decide what's app and model for your situation.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Brashear:
Thanks. I can see the timer in the model to re-capture the data from the socket but how does the controller know when to refresh to view with the current information?

The controller doesn't need to be involved at all. Typically the view would observe the model and therefore get notified by the model when it needs to show new information. See the Observer pattern.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
I think one could argue for the timer in the controller. Refreshing at some interval might be an "application" decision rather than a universal "model" feature.

In my understanding, the model in MVC doesn't need to be "universal". The Controller's one and only responsibility is to translate user input into actions in the model. The view displays the model to the user. Everything else in this respect - wether application specific or "universal", is part of the model.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm, timer could be an actor. Dunno if it could play that role in MVC or not. Or you could say it's simulating a request from the user.
I made up the word "universal" so it really has no meaning. Sorry about that. The real point was the model should not be bothered with how it is being viewed by one interface or another. Is the refresh a feature of the model - an "always up to date" quality - or a feature of the UI? Could go either way, I suppose.
I'm fighting to stay awake and not collapse on the keyboard, so I may be completely out of my mind.
[ April 02, 2004: Message edited by: Stan James ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
Hmmm, timer could be an actor. Dunno if it could play that role in MVC or not. Or you could say it's simulating a request from the user.
I made up the word "universal" so it really has no meaning. Sorry about that. The real point was the model should not be bothered with how it is being viewed by one interface or another. Is the refresh a feature of the model - an "always up to date" quality - or a feature of the UI? Could go either way, I suppose.

Here is my reasoning:
- If you change the way data is represented, say from Swing to a textual console app - would you want to change the timer? If not, it's not part of the View.
- If you change the way the user interacts with the app, say from mouse input to voice recognition - would you want to change the timer? If not, it's not part of the Controller.
- If it's neither part of the View, nor part of the Controller, it's part of the model - at least regarding the MVC pattern.
 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is meant by "timer could be an actor"? Also, could this same sort of
application be written as a web-app as well?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Brashear:
What is meant by "timer could be an actor"?

I think Stan meant that you could see the timer as being outside of your system, generating input in the form of events telling the application to do its work.
Also, could this same sort of
application be written as a web-app as well?

Certainly. In fact, when using an MVC architecture, ideally the model shouldn't be affected by this choice at all.
 
S Manch
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought Model of MVC should explicitly contain only the business rules that guide the application!, timer - is a mode of input which I think should be a part of the controller.
If we have the timer in the model and some time down the line if the application should cater to input from two sources - timer as it currently has and a new web based interface then the application is not extensible! because it always is expecting the input through a timer.
Or another example is let us take a domain where there are different teams of programmers the business rules developers who are well versed in business rules should they be concerned about modes of input?
IMHO.
sanjay.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by S Manch:
If we have the timer in the model and some time down the line if the application should cater to input from two sources - timer as it currently has and a new web based interface then the application is not extensible! because it always is expecting the input through a timer.

The "business" of this app is, according to the original poster, to poll information from a unix box in a regular intervall. If you add a requirement like "poll for information on demand", you certainly have to adapt the model. But that shouldn't be hard.
On the other hand, say you want to change from the polling technique to a pushing mechanism. Would you really want to touch both the model and the controller for this?
Or another example is let us take a domain where there are different teams of programmers the business rules developers who are well versed in business rules should they be concerned about modes of input?

As the original poster wrote, the "business rules developers" *are* concerned about the refresh rate, because of network traffic constraints. Also, it's the responsibility of the domain experts to decide wether to use a polling technique (which is the reason for the existence of the timer), not the UI expert's. Or so it seems to me.
 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If this application has a "web" version as well as a windows app wouldn't the model be the only piece that you wouldn't have to have a separate version of? Also, how would the "timer" be implemented in a web application?
Thanks.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Barry Brashear:
If this application has a "web" version as well as a windows app wouldn't the model be the only piece that you wouldn't have to have a separate version of?

Yes, as both user input and output to the user needed to be implemented differently.

Also, how would the "timer" be implemented in a web application?

If you use HTML (instead of an applet or something), you could let the page refresh itself every couple of seconds. Of course your model still needs to make sure that the polling occurs at the 10 second intervall. So you actually would have two timers - one in the view and one in the model.
But wait, here is an idea - you could redefine the requirements (for the model) to "poll the unix box on demand, but not more often than every ten seconds - use a cached value in that case". Now the timer implementation, that is, how often the view is updated, can be the responsibility of the controller. Mhh, I feel as if I'm missing something...
 
S Manch
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If timer is a part of the business rules that guide the application!...then as ilja says "timer should be in the model"....BUT if you expect the input modes to change in the future...then it should be in the controller...there isn't much info. in your original post for me to infer that information...
Bashear wrote:
>>If this application has a "web" version as well as a windows app wouldn't >>the model be the only piece that you wouldn't have to have a separate >>version of?
the above post is a little confusing to me...BUT if you are thinking about having two versions of the model for two modes of input then...if there is any change in the business rules...which there is very often..then you have to change in two places....now if you add other modes of input like a SWING, VC++ front end.. (Timer/Web/Swing/VC++) then you have to have 4 versions of the model....which means more changes...

sanjay.
 
Barry Brashear
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can you have the page refresh every few seconds? Would this refresh go to the controlling servlet?
 
S Manch
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>>How can you have the page refresh every few seconds? Would this refresh >>go to the controlling servlet?
there is a meta tag attribute...that would refresh the page every N number of seconds...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!