By adopting a Model - View - Controller architecture, you have committed yourself to a portion of the design space that both limits your choices of possible approaches but also provides you with guidance for addressing and solving a number of problems.
For example, it provides you with considerable guidance for decomposing the problem into a set of first level components, e.g., one or more controller components and multiple individual view components. It also raises the issue of communication among those components. Since this is a pervasive problem, a number of people have addressed it and you can benefit from their considerations and their solutions (e.g., using DataBeans).
Another benefit is that this architecture is especially good for building fast prototypes so that you can develop and test user function early by building the view and controller components first and merely stubbing out the model components. Once they are working satisfactorily -- with model methods returning plausible data -- you can turn your attention to providing actual function.
In the discussion that follows, I will try to identify some of the problems, issues, and questions that are inherent in a class of Web-based software -- systems that support multiple users but provides each of them with his or her personal own personal data separate from the data of all other users. An extension of this class of system would be those that also support communication among users and the sharing of data, but those features are not included in the class discussed here.
Keep one user's actions and data separate from the actions and data of other users.
One can imagine a system where users share data and may interact with one another's data, dependent upon various constraints. For example, file systems can be configured to permit all users to read but not write certain data. Since this assignment uses a database and tables to provide persistent storage, one must design mechanisms to keep data confidential and to control the range of searches.
What are the major application components and the relationships among them?
In this example, one might identify user, login, and addressbook as three major components. Not so obvious is the question of the relationships among them.
For example, how many times may an individual register and create a user profile? Is there any way the system can or should be able to determine this? How many logins can a given user have? Is data associated with a user or a login? One set of answers is inherent in the executable part of the problem statement, but you may wish to go a little further in your design.
Consider potential future needs in your design.
Over designing and over building are major problems -- you don't want to include large amounts of code and function that may never be used. but, considering the problem in light of likely future enhancements can also be beneficial. It may be that a modest extension beyond basic, first-level requirements at the outset can greatly reduce costs and problems down the line.
For example, a basic set of functions for database-supported systems is the capability to create/add, retrieve/get, update, delete, and, search entries (CRUDS). This application, as currently defined, does not require all of these operations. In my implementations, I usually provide all of them at the outset if for no other reason than debugging.
But don't over do it!
Maintaining state
There are several issues to be considered in maintaining state -- that is, having information that originates in one interaction with the system available in another interaction with the system. Issues include what information needs to be maintained across requests? How is that information to be stored and retrieved? Where will that information be used and for which specific operations?
Examples of information that may be needed over multiple requests include identity of the user, his or her user type (e.g., administrator, registered user, guest, etc.), the context from which a request comes (e.g., particular window or instance of a form), prior data (such as previous search results) that may be relevant for the current operation.