CODEWITHSUNDEEP
javamodel-view-controllerclient-server
habitats
habitats

Reputation: 2461

How to implement MVC into a server/client/DB application

I'm writing an application consisting of a gui interface, a client, a server and a database.

However, after countless hours I still haven't figured out how to organize it all.

The GUI is built up by several rather different swing components, so I thought about having a separate model for each of them.

The information flow is currently like this:

  1. User inserts some info in the GUI.
  2. GUI tells the controller something happened by giving the controller an event.
  3. Controller sends the event to the server
  4. Server evaluates the event and sends the appropriate query to the DB.
  5. Results from the DB are then attached to the event, and sent back to the client.
  6. Controller picks up the event and updates the appropriate model with the new information
  7. The model then updates the corresponding view.

A possible scenario could be the user searching for entries through the GUI, and having the results returned.

Does this architecture sound sane at all?

Should all the different views have their own model? If yes, should they have their own controller as well? If no, then what?

I thought about sending the entire model to the server, and having the server manipulating the information in the model, then send it back to the client. When the client then receives it, the controller makes sure the new model info is getting attached to the view. This solution eliminates the need for separate events classes, but it doesn't seem right to do this.

I guess what I'm asking is what is the best way to organize a server/client/db application following the MVC-pattern?

Upvotes: 0

Views: 1870

Answers (1)

iberbeu
iberbeu

Reputation: 16205

The best way is to separate the Client, server and DB.

What I mean with that is that the first step is to know what has to be done in the client, what in the server and what in the DB:

Database:

The database is actually nothing else than a database so there is nothing that it can do

Server:

in the server you should do everything that might happen on the server: accessing the database, accessing files,...

Client:

The client will do the rest. Here you need to separate between "showing data"; that would be the "view" and managing data; that would be the controller. For providen the gui with functionality you use the "controller" so at the end the MVC model remains within the client

I think therefore that your idea is not as bad as you think. I'm working on a project that works like that. We are working in the way I described and I can ensure that everything looks very nice. Everything is separated. The server and client can be replaced without having to change something in the other. If we change the database only the server will notice it, if we change the gui library (swt, awt, swing...) only the client notices it. Both server and client can run in different environments and none of them notices it.

So if I were you I would do it as you said. Give it a try and you'll see that it works perfectly. As I said I'm following more or less the same workflow and I can tell only good things.

Upvotes: 1

Related Questions