hello
Ive read about the Model-View-Control Architecture and understood it ,theoretically atleast!! Ive found huge coding fr explaining the concept. Thus I am unable to visualise this pattern in terms of coding. Can someone please explain it to me with a simple example and some method abstractions in there..
Thanks a ton (in advance)
Priyank
The simplest way to visualize it is this:
View == User Interface (Swing or JSP)
Controller == object that the View sends requests to (e.g., RMI listener for Swing, servlet for JSP)
Model == all the objects that represent the data for the problem you're trying to solve (e.g., Person, Order, LineItem classes)
A client uses your View to send requests to the Controller. The Controller interacts with the Model objects to fulfill the request and sends the response back to the View.
Add another layer - Persistence, because you might want some of your Model data to be available after the program or session ends.
%
> okay....i understand this...
> i am currently implementing a db project in
> Jswings...
You mean Swing?
> Can u pls tk up a hypothetical example n explain me
> d working of M-V-Cin tht...
> Thanks a TON!!!
OK, in this case you have two choices. You can model this as a client/server problem where all the logic is built into your Swing client. It connects to the database server in this case. It's the easiest one to code. (I recommend that you do it this way if it's your first project.)
The second choice is to write an RMI listener that the Swing client contacts. The RMI listener is the thing that talks to the database and sends results back to the client. (RMI is a bit more complex.Ever done RMI coding?)
In this case, your Swing client is the View. You'll probably use the javax.swing.JTable class for the View. It has a built-in notion of a Model with its javax.swing.DefaultTableModel. The Controller function is carried by the Listener classes you'll implement. They'll respond to events like button clicks, etc. and perform operations with the database.
%
ok..i think ill give u a brief idea of what i am implementing..thn itll be easier fr u to visualise my condition..(n yea its swings only!!)
I have different functionalities like add search edit update delete tht is to be performed on some data. Ive designed these GUIs. ive done some layerwork..like implemented the DTO,Service,DAO layer My DAO layer interacts with db...( I DONT knw abt RMI programming) i use flow of control divided amongst these layers. ex:: Ive displayed my search results in frm of a table..which works on MVC..i want to extend the same to my main coding....example...
ADD feature::
Model = all the fields the user may enter
View = my user design
Control = Operations being performed on my ui in sync with model+ some setter methods
Nw first of all i want to confirm my understanding with this example and how do i implement this feat with MVC...give me some tips so tht i can code it
Thanks..
Priyank
> ok..i think ill give u a brief idea of what i am
> implementing..thn itll be easier fr u to visualise my
> condition..(n yea its swings only!!)
>
> I have different functionalities like add search edit
> update delete tht is to be performed on some data.
No surprise there - these are standard CRUD operations on relational tables.
> Ive designed these GUIs. ive done some
> layerwork..like implemented the DTO,Service,DAO layer
OK. Does that mean you've written code? What does "design" mean to you? A sketch of the UI?
Want a great example of what yours should look like? Download and run SQL Squirrel. It's a beautiful UI for databases, all in Swing.
> My DAO layer interacts with db...
Yes, that's what DAOs do.
> ( I DONT knw abt RMI programming)
RMI isn't necessary in the DAO.
> i use flow of control divided amongst
> these layers. ex:: Ive displayed my search results in
> frm of a table..which works on MVC..i want to extend
> the same to my main coding....example...
> ADD feature::
> Model = all the fields the user may enter
> View = my user design
> Control = Operations being performed on my ui in sync
> with model+ some setter methods
> Nw first of all i want to confirm my understanding
> with this example and how do i implement this feat
> with MVC...give me some tips so tht i can code it
> Thanks..
> Priyank
Tips? Go download SQL Squirrel and use that.
If you must code it, make yours as good as SQL Squirrel. That'll be a nice, educational job.
Stop worrying about making the perfect MVC implementation.Get something working and see what you can do to make it better once it's running.
%
>>OK. Does that mean you've written code? What does "design" mean to you? A sketch of the UI?
I have written down the code...n fortunately its working :D...the thing is running...but i think its pretty messy....so i thought segregating some things...maybe partially ...might help me....ill see SQL Squirrel
Id like you to tell me as to wht kind of code goes in these three MVC
Thanks
> >>OK. Does that mean you've written code? What does
> "design" mean to you? A sketch of the UI?
>
> I have written down the code...n fortunately its
> working :D...the thing is running...but i think its
> pretty messy....so i thought segregating some
> things...maybe partially ...might help me....ill see
> SQL Squirrel
>
> Id like you to tell me as to wht kind of code goes in
> these three MVC
> Thanks
I think I already have, short of writing it for you.
All your persistence code belongs in DAOs. No one gets data without going through a DAO. These should be interfaces.
You should have a service layer that maps closely to your use cases. These should also start with interfaces. The service implementation should be the only ones that instantiate and use DAOs. They do the work of orchestrating what gets done.
The controller(s) do little more than figure out what event has occurred and send the information to the right controller.
Java event Listeners will be your Controllers in this case. They "know" what event has occurred. They'll instantiate the correct Controller and hand it whatever information it needs to accomplish the requested task.
%
In this case there's a good argument that the Listeners ARE the Controllers.
If the Listener invokes the Service interface to accomplish the task triggered by the event, I'd say that's sufficient.There's a lot to be said for this arrangement:
(1) Listener is an interface already
(2) If you implement the Listeners in a separate package and add them to the View via constructor or setter, then the View and Controller layers are truly separate.
If those Listeners are using your service interfaces, I'd say you're in good shape.
%
> (2) If you implement the Listeners in a separate
> package and add them to the View via constructor or
> setter, then the View and Controller layers are truly
> separate.
>
Right now, I have implemented in the following manner::
View contains a button say "SUBMIT", when i clik on it:
it fires an event and delgates to the standard ActionListener,
Then i make a call to my service layer and to subsequent layers from thereon.
As far as ive understood, i'd have to define my own listeners and somehw add these listeners to the Events generated in View. It is then the duty of MyDefinedListner to delegate it to the standard listener and make a call to service layer...rite?
If so, my dumb brain fails me in identifying as to how will i add this MyDefinedListener to the View Gui Button (should i follow the same technique as used in the delegation model and slip in the code of service layer invocation there?)
Thanks
> Right now, I have implemented in the following
> g manner::
> View contains a button say "SUBMIT", when i clik on
> n it:
> it fires an event and delgates to the standard
> d ActionListener,
"standard" ActionListener? There's an ActionListener interface, but no standard implementation.Your code should register an SubmitActionListener to fire whenever your Submit button is clicked.
> Then i make a call to my service layer and to
> to subsequent layers from thereon.
Yes, I think that's a good separation.
> As far as ive understood, i'd have to define my own
> listeners and somehw add these listeners to the
> Events generated in View.
What I'd recommend is either have the constructor for that JPanel take in parameters for each ActionListener that's needed OR have setter methods that allow you to set the required Listener.
That way your view Swing classes don't have any Listeners hard-wired in - they're passed in by the main Controller that actually has the main method that starts the app. The view doesn't know anything about how it gets the Listeners, just that all the required ones are made available.
> It is then the duty of
> MyDefinedListner to delegate it to the standard
> listener and make a call to service layer...rite?
Each Listener will have the implementation they need to accomplish what you want.
> If so, my dumb brain fails me in identifying as to
> how will i add this MyDefinedListener to the View Gui
> Button (should i follow the same technique as used in
> the delegation model and slip in the code of service
> layer invocation there?)
> Thanks
If you have X buttons, you'll have X Listeners, one per button.
%
If the Listener invokes the Service interface to accomplish the task triggered by the event, I'd say that's sufficient. There's a lot to be said for this arrangement:
Definitely. In fact, most of my standard client-server controllers are normally listeners. With a few important caveats:
> Generally, I do not like placing View objects within a given Listener. If callbacks are necessary, I write a separate class for those.
> Generally, if state needs to be tracked by the controller, add instance variables to the Listener, rather than the View.
Otherwise, Duffy's comments are spot-on as always!
- Saish
