0

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?

Improve this question

1 Answer 1

Reset to default
1

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

So, having a different model for every different view, and control it all with a single controller is a reasonable way to do it?
I would rather suggest having the same amount of controllers as of views or groups of views, that depends on your architecture. In that way the different views will also be isolated from eachother. One controller for the whole thing can be two much work for just one class. Try using inheritance

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.