I am trying to implement MVC for my Java desktop application and I am not very familiar with it. For the purpose of the question, I am considering a use case in which you click "refresh" button, it queries DB for list of students and update students lists. Here are my questions that have been confusing me:
1-For querying the DB, does it happen in the controller or in the model? My gut feeling says its controller who queries and once results are received, it updates the model. However I read in many posts that the Model is the one who knows its state transitions and does its updates!
2- Who creates the the view and model? Does the controller create them or are they created externally and passed to the controller?
3-In the above use case, does the model consists of an ArrayList of Students or is the model just a Student object but the Controller has and ArrayList of models?
Please help a fellow developer
For querying the DB, does it happen in the controller or in the model?
Short answer, querying the database happens in the model.
A List of Student is the model for the GUI, where Student is a Java object containing the student information. The list of students is also the model for the database.
There are different ways you can approach the interaction between the list of students and the database. One way is to read all of the student information at the beginning of your GUI initialization. As your users interact with the GUI, your GUI controller inserts, updates, and marks students for deletion in the GUI model. Finally, when the user closes the GUI, you write all of the changes in the list of students to the database. This way, while simple, exposes you to data corruption if your GUI abends. Also, only one person can make changes to the database at a time.
A better way is to read all of the student information at the beginning of your GUI initialization, as before. As your users interact with the GUI, the GUI controller updates the list of students in the GUI model. After each insert, update, or delete, you call the appropriate methods in the data access object to insert, update, or delete the student information, respectively.
Who creates the the view and model?
You do. :-)
The model / view / controller pattern is not just for organizing code. Generally, you create the first cut of the model first. Then you create the view, and add the fields to the model that you forgot when you created the first cut. Lastly, you create the controller. The controller(s) should do nothing but execute methods in the model to update the model and methods in the view to repaint / revalidate the view.
You pass an instance of the model and an instance of the view to your controller(s). You should only have one instance of the model and one instance of the view. However, they are not singletons.
In the above use case, does the model consists of an ArrayList of Students or is the model just a Student object but the Controller has and ArrayList of models?
Finally, an easy question. Neither.
Your model is a List of Student. The List interface will be implemented by the ArrayList class. Something like this.
List<Student> studentList = new ArrayList<>();
By using the interface, you can easily change the ArrayList to a LinkedList, or your own implementation of the List interface.
A general Java rule is to use the interface unless the methods you need are only defined in the concrete class.
I hope this was helpful.
Related
I'm working on a school project and or task is to design a project management tool. We are allowed to use any design pattern as long as we can explain how it's good according to the GRASP principles.
I'll give a synopsis of the project tool:
CRUD-functionality for projects
CRUD-functionality for tasks (a project has tasks)
CRUD-functionality for users (a user is assigned to tasks)
A simple GUI
We decided to go with the MVC-pattern and we are not allowed to use a database. My question is: Where should I store objects?
Should I do this in the controller? Currently we do it like this:
public class ProjectController
{
private ArrayList<Project> projects;
public ProjectController(TaskController taskController)
{
projects = new ArrayList<Project>();
}
}
I have a feeling there is something wrong with keeping the objects in the controller but I can't explain why. Anyone that can explain what's the best practice according to the GRASP-principles?
EDIT:
Thank you, learned from everyone something but can only pick one answer.
For a very short answer : NO, don't put your store in the controller. This is a bad idea and it goes against the MVC principle.
Usually, the model is the only place responsible for your data BUT it is frequent that the M part is split into :
Fetching the data.
Storing the data in the application.
The interesting part in this is that, no one cares where your data come from. A database, a file, an API rest. whatever, it doesn't matter.
I'm not saying i have the best solution for you but here is how you could do this with an example.
You store your user data into a file.
You create a php class UserDataRepository that fetches the user data files, and sets the data into your UserModel class.
From the controller, you call your UserDataReposiroty and get back your UserModel.
This way your controller doesn't have any idea how you are fetching the data. He just asks a repository to fetch them and it returns the UserModel that the controller is allowed to manipulate.
I hope this will help you
Increase abstraction.. Create a model class. Create your arraylist (model objects) there. Your controller should still access/call model methods.
Tomorrow, you might want to dump that data into a file or into a DB, you will have one hell of a ride doing that with the current design. So separate your model from your controller and keep the design clean.
No. If you store data in the controller then you are not using MVC. You have to do it in the Model. You can store in memory or files, but always store data throw the model. For example, you could implement DAO pattern to manipulate data.
Maybe, not now, but then you will need a database. With DAO pattern, it won't be difficult to adapt your current persistence kind to a database.
In MVC pattern, M means models, V means view, C means controller. A common MVC application progress is that once a request is coming, controller get it and do necessary processing, retrieving results data, then pass the results data to view for rendering. After view layer is rendered, it displays to users via GUI.
So controller can be regarded as a commander, it controls process, but it is not good to handle data retrieving in controller. Model should be responsible for retrieving and organizing data. That means data objects should be stored in Model instead of Controller, Controller calls Model to retrieve data objects. Take Java application as example, usually these parts are needed:
ProjectController, it calls ProjectService.getAllProjects() method to retrieve result. Once retrieved, view layer use the result to render GUI for display. I suggest Controller layer should be thin.
ProjectService, it has method getAllProjects(), this method calls ProjectDAO.getAllProjects() method to retrieve projects data, and maybe other handling. Here business logic goes.
ProjectDAO, it has several methods which deal with Project objects, deal with data in this layer! But these methods should be independent with business logic(as business logic should be deal in ProjectService).
Project object.
Hope it helps.
In an example I got at school of the MVC pattern we had 3 classes Student, StudentView and StudentController. The controller has an instance of the model (Studentin this case) and an instance of the controller. The problem i have with this is that the controller only handles a single object.
You obviously can have more students so I have an ArrayList<Student> somewhere. where do I put it? and how do I handle the model and view then?
My initial thought was to put the list in StudentController but then I found out that the controller is no longer for a single instance of Student but for the list so do i need to make 2 seperate controllers? one for Student and one for the ArrayList<Student> called something like AllStudents?
Edit: The application is a simple grading system for students. Students follow Coursrs the and a Course can have a Grade. the View displays the data of the student, course or grade in the console. The data is hard coded in the programme (objects are made 'on-the-fly').
The Model is not necessarily just one class, it's a layer. Your Student Class as a Domain Object in your model layer now you need a Service and maybe some kind of a persistence/orm in your Model. A Service could be StudentService with methods like getAllStudents() returning a List. The StudentService may have an instance of a Connector to get the Data from a Database or a File.
That is a question leading to the much broader question of: what does the rest of the application do?
It is obviously totally fine to have a 1:1:1 relation between view, controller an model. wht you might be interested in is an event bus. When the model of interest changes, the controller gets notified and updated with a new Student reference.
Or the controller gets the whole list and the view sends an event to the controller indicating that a different instance from the collection should be displayed.
In many application you'll have a master and detail views. The master view displays a list of all students. When one student is selected to be displayed in the detail view, a notification/an event is dispatched. This is basically a publish/subscribe observer/subject model. The detail view controller will be notified and display the proper data accordingly.
As an amateur I'm writing my first layered Java application which uses JDBC to connect to a MySQL database.
I've structured my application in four packages, one for each layer: model, view, controller and database. The database classes serve as Data Mappers as showed here:
http://martinfowler.com/eaaCatalog/dataMapper.html
This design suits well for inserts, updates and deletes, but how do I handle multiple rows returned from a ResultSet? Should the Data Mapper be aware of the model and call its methods?
Let's say that I want to show my results in a JList in the view. Which class has the responsibility to retrieve data from the ResultSet and put it into the JList?
Let's say that I want to show my results in a JList in the view. Which class has the responsibility to retrieve data from the ResultSet and put it into the JList?
In my opinion that would be a Controller, but it will delegate this responsibility to Data Mapper. Mapper should return real objects (parsed from result set)
This design suits well for inserts, updates and deletes, but how do I handle multiple rows returned from a ResultSet? Should the Data Mapper be aware of the model and call its methods?
Yes, Data Mapper should be aware of model structure. This is purpose for this kind of object to exist - it know how to store model object in database, and know how to retrieve itfrom database.
When you create Data Mapper (or Data Access Object or Repository or whatever), you create something like "crumple zone" in your code. When model change, you need to fix only Data Mapper. Without Data Mapper abstraction you will probably need to change many places in your code which will take much more time.
In general your Data Mapper can use methods of model object to set it state. Other way is to create fields in model object with "package private" access modifier - so if you put Data Mapper in the same package - it can directly set those fields.
I am having some troubles understanding and implementing the MVC pattern.
I have a singleton "model" class which contains all the datas of the application and extends Observable. When those data are modified, I want to update the views, and when one of the views receives some input from the user, I want to update the model. In between stands a Controller (implements Observer) which has an instance of both the view and the model.
I think that to do this, the views must have an instance of the controller. Whenever it receives an event from a button or any component, it calls the correct controller's method, which transmit the informations to the model. The model is updated and notifies the observer which in turn will update every components of all the views, even if they are not linked to the particular data which has been modified, since the Controller can't know what has been modified in the model. I am not sure this is a good design.
I looked a bit upon the PropertyChangeListener class, which seems to correct this issue but I am not so sure that I understand everything. Is there any preferred way to do this ?
Thanks in advance !
There are a few issues with what you're suggesting.
First of all, you're describing MVVM, not MVC.
The second problem is that the terms model and controller aren't suppose to describe singletons. They are merely terms to help you separate concerns by organizing your logic into classes with well-defined responsibilities.
The MVC structure is as follows:
The Model
This is your application logic/business rules. This basically means that if your application is about a phone book, then all logic and data structures that have to do with providing a phone book API is implemented here.
The View
This layer is completely separate from the model, in that it doesn't care about data structures or logic, but only on presenting simple values. Strings, integers, collections, you name it. But it doesn't care about the model's API, it only depends on the controller's.
The Controller
This is where things come together. The controller is the mediator. It speaks the language of the model, and that of the view, and it can make them work together. User requests are routed to the controller.
For example, a request might want to list all numbers in the phone book. What happens is:
The controller receives the request
Asks the model for all numbers that exist in the phone book via the model's API
[Optionally] converts the data into a data structure which the view is intended to display
Passes the data to the view
One last remark before we finish:
If the controller doesn't convert data from the model into something simple, then allegedly the view is now tightly-coupled with the model. However, that doesn't always have to be the case. Even if the model's API changes, then the controller might still be able to adapt the new API into the old API, which the view already understands.
I'm currently building a Java GUI application and I'm about to implement something that seemingly requires a great deal of thinking, at least for someone as relatively inexperienced as me.
The situation
is as follows: I have a class Customer at domain level, that holds a collection of jobs, which is a class too (Job). The application is for a fictious gardening company that wants to manage its customers and the jobs it does for them.
At GUI level, I have a jList for all the customers, with a custom listmodel that extends AbstractListModel. This part of my application works perfectly, I can add/edit/remove customers easily and as it should be.
The goal
now is to implement a jTable that should show the jobs for the customer selected in the jList.
No doubt I'll need a custom TableModel, the question is: where to get the data from? It should be noted that the collection of jobs in the Customer class is an ArrayList, and the class has no method that returns this ArrayList directly, it is only possible to get a copy, since I don't want it to be possible to mutate the collection in the class directly from a public context.
My idea
Is to let the tablemodel have a method to change the internal collection, with a customer parameter. When the index in the jList changes, that method should be invoked, so that the jTable represents the Jobs that have been done for the customer.
When I have to edit/create/remove a job, the changes are always done on the tablemodel first, which will propagate the changes to the customer object (in case of a new job or job removal).
The question
Is that a good way to implement it? I feel it is not, because if I forget to do any changes to a Job via the tablemodel, and on the Customer or Job directly, there will be inconsistency and trouble. Are there better ways? If it involves changing other stuff, I do not mind.
(optional) Small subquestion
I lack some knowledge on the different Collections in java. I usually just go with ArrayList, like in this case in Customer for (mutable) jobs. Is there a better collection for this?
Not saying this is the best way to implement this, but this is how I would do it
Make sure the customer Job list is observable. Either by using a 3th party lib which provides collections which fire events (I think Google has some available), or just make sure that every method on the Customer which updates the Job collection fires events
The table model representing the Jobs for a certain Customer can then listen for those events and update itself accordingly
It is unclear whether you allow to make changes to the table ui, but if you do, the table model should be responsible to propagate those changes again to the Customer
So nothing changes on your current edit/create/remove/add job code. That keeps working with your Customer and does not even know a TableModel exists. The TableModel works also directly against the Customer and does not even know there might be UI to edit/create/remove/add jobs. It just listens for any changes made to the job collection and updates itself accordingly.
It seems like a very bad idea to make the changes to the job list in all parts of your code through the table model. The Customer is your model, and the JTable is the view (MVC pattern anyone). The fact the JTable needs a different representation of your model (a TableModel) is a side-effect.