• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: future functionality enhancements?

 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,
My assignment (URLyBird) says:
Your user interface should be designed with the expectation of future functionality enhancements and it should establish a framework that will support this with minimal disruption to the users when this occurs.


Is this taken care of by the MVC scheme? I have a model class (extends AbstractTableModel) and a view class (that presents the JTable). I seem to be able to get by without a separate Controller class - my view class
calls methods on the database directly (via the Data class). If the GUI has to change, I will make changes to the view class but is this good enough? The quote above hints at something further that one can do (a framework?) but I don't know what. Any ideas?
By the way, when people talk about 2 tier and 3 tier solutions, is the 3rd tier the controller or do they mean something else?
regards
Simon
If the design changes and I have to modify the GUI
What do they mean?
 
Charlie Goth
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think that's how you're supposed to use MVC.
The View should be the gui as a whole.
The Model would be the connection to the server.
The Controller would be in between.
I understood the future enhancements to mean that extra functions can be added to the gui with minimal effort, using a JMenuBar would go a long way towards this (IMO).
I wasn't sure what 2-tier and 3-tier meant but I looked it up:
3-tier Client Server
I'm not sure how we can do 3-tier as we only have to applications (client & server) and not a database - or is the db file the third tier?
So, is your Data class (this is the one that implements the provided interface right?) is talked to by the client? Mine is only on the server and completely hidden from the client.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use three tier architecture, even in a client/ server environment. It's really all aobut about how you organize your project.
For example, if you have one tier( say package), that's responsible for interacting with the file system, that's your deepest tier.
Next, you might have a tier( say package, possibly with sub packages), that's responsible for your business logic and/or remote connection.
Finally, you might have a presentation tier( again, think package), that's responsible for your presentation. This piece might have it's own structure, say MVC.
It's still client/ server, but with a three tier design.
Alternately, you could have a single tier that's responsible for everything, and you'd still have a client/ server app.
HTH,
M
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys, for the info about 2 and 3 tier designs. This was a bit of an aside, however. My real question was about how to interpret the instructions for the SCJD, about future functionality enhancements. Clearly if the user wants to add new functions, we must change the GUI but the instructions seem to hint that there is something the developer can do to minimise the impact of such requests - some kind of framework. My question is what framework? The MVC design should isolate the view from the database, such that a GUI enhancement does not affect the whole application. Is this what they mean?
regards,
Simon
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Simon,
Originally posted by Simon Ingram:
Clearly if the user wants to add new functions, we must change the GUI but the instructions seem to hint that there is something the developer can do to minimise the impact of such requests - some kind of framework. My question is what framework? The MVC design should isolate the view from the database, such that a GUI enhancement does not affect the whole application. Is this what they mean?

If you've implemented the MVC design pattern in your GUI then you've already done something to minimize the impact of future functionality on the GUI. So, yes that's what they mean. You could point out in your design choices document how the MVC design pattern helps to support new functionality as you've already done above.
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, George! I had a feeling someone would say this. Problem is that I have an MV pattern, if such a thing exists. i.e. no explicit class acting as a controller. OK, I admit to feeling a bit guilty about it, but it seemed so easy to call methods on the database directly from the gui! In fact introducing a controller seems to complicate matters, but I am still left with an MV and not an MVC and a sneeky feeling that I may be in violation of the OO design rules. My question is, am I the only one?
By the way George, that was an interesting post you submitted about the cyclical dependencies. I had never heard of them before but they sure sound nice and scary!
regards,
Simon
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Please take into account that I am not a patterns expert.
My "view" is my graphical user interface. The model is
what is stored in the database. And the controller, is
the part you left out of your MV pattern.
By calling the database functionality within your graphical
user interface, it is not MVC, as you have stated; and, I
suspect that most people don't do this.
Although I may stand corrected by subsequent posts, it's
very easy to get an MVC pattern (again, with the caveat
that I'm not a patterns expert). This is done by simply
having your GUI talk to, let's call it, a user interface engine
class, perhaps called engine. The engine acts as the "controller",
although, when actually implemented, the engine simply separates
out logic away from the GUI:
public class Gui {
private Engine engine = new Engine();

private void readAllRecords() {
StringVectorOrWhatever stuff = engine.readAllRecords();
then stuff is displayed within the user interface.
}
}
In some designs, the engine class can call back into the Gui
class, if that is necessary.
In short, if your Gui class gets things done by talking to
an Engine class, and the Engine class in turn calls the
business methods (lock, update, unlock), then you probably
have the MVC pattern. It is my opinion that you should
definitely use the MVC pattern, if for no other reason than
that it makes the code more understandable and clearer.
Thanks,
Javini Javono
 
Simon Ingram
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Javini,
thanks for your suggestions! I too am no patterns expert. I tried reading Design Patterns by Gamma et al. and kept falling asleep! I read Max's stuff on the MVC which was better (you know this book on the SCJD exam, I hope) and in his example using serialised objects you could see the point of the controller, but in my project (URLyBird) it is hard to see the role for a controller class.
In your example, you call the business method readAllrecords() on the engine class, but the engine class is exactly the same as my Data class! Perhaps I have an MVC after all!
regards
Simon
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Simon,
There is a good example of a Model View Controller in the thread "Confused with MVC".
Regards, Andrew
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Simon Ingram:
Thanks, George! I had a feeling someone would say this. Problem is that I have an MV pattern, if such a thing exists. i.e. no explicit class acting as a controller. OK, I admit to feeling a bit guilty about it, but it seemed so easy to call methods on the database directly from the gui! In fact introducing a controller seems to complicate matters, but I am still left with an MV and not an MVC and a sneeky feeling that I may be in violation of the OO design rules. My question is, am I the only one?
By the way George, that was an interesting post you submitted about the cyclical dependencies. I had never heard of them before but they sure sound nice and scary!
regards,
Simon

Simon, as far as I see the software development, losely coupling is the key that allows for at least two great software benefits:
[ul]
[li] Reusability [/li]
[li] Flexibility [/li]
[/ul]
We may add Scalability, if we think that a separate business logic tier(package) as Mr. Habibi said, could be implemented in another server (this is what happens with EJBs).
When you think at the MVC architecture, IMO, you shouldn't keep too strictly to the "Controller" as a unique address point where the GUI dispatches requests, although a single point well organized (as Mr. Habibi shows in his book) would be beneficial (this is also what Struts brought into web-applications). You may see at the "Controller" as a separation between what's presented to the user (which may also change format) and what's required to the business logic.
Swing natively implements a layer of separation, through the Event delegation model. At the end of the days, for each control defined in your GUI, you register a class (internal, separate, unique...this doesn't matter really, provided that you defend your choices) that implements a listener and it's in this class that you actually ask to the system to "perform something useful". It's this class that represents the "Controller", therefore I may imagine that you've already got a MVC architecture. The real difference is whether you want to use a single "Controller" class which implements all the business logic interface (and delegates the real work to the framework tier), or you want to write a separate class for each GUI relevant action, or a mixture of the two.
Honestly, letting your GUI "talking directly" with the database, seems to me a very bad idea, because it highly ties your presentation tier with the business logic. What if tomorrow your underlying database framework changes? (Just an extreme idea: let's say tomorrow Sun deprecates streams! You would need to phisically change the code in your GUI, while if your GUI, through the controller, simply delegated the database-related functionalities to a business-logic framework, you would have only to change the latter).
Hope this will help,
Marco
[ March 11, 2004: Message edited by: Marco Tedone ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic