One first question you should do to yourself is: How big is this system?

This question is important because this can make you choice from two different approuches...

1) If the system is small and you just need to show the contents of a database, you can stick to the MVC used by struts, or others... wich mean that the Model object is the database encapsulation.

2) OTOH, if the system is supposed to be a little bigger, and you're not just showing the contents of the table, but you have to deal with business rules you probably want to create a more sofisticated design...

In this design, you would split your system in two parts, one as a Service Provider that would provide the needed services to retrieve and save the information, so you can implement multiple interfaces, or interface with other systems (see Web Services Architecture in w3c website)...

The not-so-obvious implication is that the Model object will not necessarly represent the plain table, but could also include some calculated information, some object's relationships.

Now to the implementation:

The main key to MVC is a magic keyword named: "event". The key is... When the model is changed, it notifies the changes, so if the model is changed by the Controller (I mean, loading the data) the UI is updated, and if the UI changes the Model, the controller can be notified and do some extra calculation (I mean, sum the values and set the total value in the model and the UI will be notified).

The big difference is that when you want to fetch the data to send to your service, you will not traverse all the components getting the values, the model will be already in the format you need to pass to the service, thus, reducing the complexity of the user interface.