I have a class called Member which I use as the model for one of my views. This view allows the user to view and edit details of a particular Member. My question is what model should I use for a different view that allows the user to add new members? Should I use the existing Member class and adapt it for this use, or should I create a new model class dedicated to adding new Members, and if so what should it be called?
If I understand you right, you have a class Member which does, contrary to what one might expect reading the class name, not represent a single Member but rather a MemberModel. This could be a mere naming issue.
Suppose your class Member has the capability to add, edit and grant access to particular members (directly or indirectly), it would make sense to adapt your existing model class so that it supports adding new members- for example by adding a method addMember() which can be called by the corresponding views.
It is fine to manage the functionality of accessing, editing and adding members via a single model. The model provides methods to your views which enables them to access, edit and add members and makes it possible for views to listen to changes of the model they are interested in (e.g. via listeners).
Depending on factors like the complexity of your project it could in principle make sense to divide your model into submodels, so that your model will be a composition of submodels (represented by individual classes). However, the role of serving as an interface to the functionality of accessing and editing members and the functionality of adding members should be fulfilled by the same class in my opinion.
What i can understand is that you have a class Member which is a model. If you want to use a model to add a member, exposing it in top layers like controller is not appreciated. What you can do is to have a Criteria class or DTO. These classes could carry all the data that is required from the top level to DAO layer.
If this is not what you are expecting, can you elaborate more on your query.
On MVC you normaly use the same model for all the actions that depends on that model. So if you have a member model, it'll be used to create, read, update and delete The famous four operations that are called CRUD.
So yes, the best option is to use the same class, once it will do the conection with the DAO layer of your project. You can fill a member object with information and send it foward to the DAO class that will register it on your dataBase, and then the DataBase can return it empty again for the next use, or don't even return it at all since you probably won't be needing it anymore. It's simple and easy to use.
Some tip about how to best manage the Adding, Editing and Deleting.
Your best option is:
Create a screen that show the user all members and one "New", "Edit" and "Delete" button, on which the New creates a new Member, the Edit edits the selected member, and the delete deletes the selected member.
For this you can create three views (not recommended) or just one, since member will always have the same fields (right? something like "name", "id"...). But one that requires operation as parameter. So you can do something like this:
try {
View frame = new frame("add");
frame.setVisible(true);
frame.setResizable(false);
frame.setLocationRelativeTo(null);
}
catch (Exception e) {
e.printStackTrace();
}
And change "add" to "edit" or "delete" as requisitation. And on the frame called, you can just configure it to as the operation requires.
Related
I have made this simple UML diagram.
I want to have a list of treatments inside class Customer.
My question is if I need another association to make this possible.
A class diagram describes classes and not objects. A TreatmentList is a TreatmentList, regardless if you look at it from the Menu or the Customer persepective.
So indeed, if you want a list of treatment "inside" the class Customer, you'll need just to add another association between the classes you want to connect.
Now I wonder if you did not try to design user interface using a class diagram:
Main -> Menu -> List 1 or List 2 looks terribly like a flow in the user interface, more than a set of related classes. You don't need this. And lass diagrams are not meant for this purpose. If you want to model an UI Menu, you'd model a menu class, i.e a general class that could instantiate any kind of menus, with a one-to-many association with MenuAction. Perhaps ShowTreamtmentList would be a specialization of such an action.
The TreatmentList and CustomerList only make sense if these are classes, i.e. they could be instantiated into one or several objects that each represent a different list. If, for an association, you'd have a multiplicity of * on the side of customer or treatment, you would not need to add a special list/set/bag in the middle.
You don't need to use an aggregate instead of an association. Aggregate are not very uselful and appear to be overused. Prefer a simple association.
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.
we got: one abstract superclass containing one method, and two subclasses redefining this method according to their needs. Not sure how to sructure project following MVC modeling.
Like, what exactly class model should have inside, controller and view?
In the most simple possible implementation:
Your model class should do data access and no more; say for example that it should be the only one with an import java.sql.whatever, and return collections of beans fresh out from your repository.
Your controller class should call your model layer, extract information and take a decision about what to show the user and how to do it. For example: you can read a list of organization units and decide whether to send the user to a tree view of the units or, if there is only one unit, send them straight to an employee table with the people on that unit. Spring MVC controllers or Struts 1/2 action classes are nice examples of this. It should also leave the data available to the view in some accesible place (for example, as request attributes)
Your view should be a JSP (or whatever view technology you use) as simple and with as few decisions taken in it as possible; all data is retrieved and navigation decisions are taken beforehand for it, and its only mission is to paint.
For example, when writing JPA or Hibernate code, I might want to create a descendant of a domain class, say Account. The descended version represents the a form a show the user. The form only has about half the fields that are on Account. So the object I use to hold the form value should not change the other fields.
Is using inheritance to change annotations considered bad? Assuming it is not, are there any good short hands or design patterns for doing it better or more effectively?
I'd say that the case you describe here (at least how I understood it) would not be a good candidate for creating subclasses.
Basically you want to restrict the form to change only some fields/associations of an entity, right? I further assume that you don't trust the developer of the form that only the fields that should be editable are changed, hence the requirement to restrict that.
In that case, one option might be to use the DTO pattern (data transfer object): create a DTO for the form data and let the user fill its fields. Then pass the DTO to a service which updates the entity accordingly. This way you have control of which fields are editable and how the update is performed.
Another way might be to create a wrapper for the entity that throws exceptions when a setter for an uneditable field is invoked. However, that would be a runtime solution and I'd prefer the DTO approach here.
Edit:
some reasons why inheritance might prove problematic in this case:
The subclasses don't represent entities, however, you'd still have to represent the subclasses on the database (either through discriminators or additional tables)
An entity that is created by that form would always have the subclass and thus would not be editable in other places (unless you mess with the database etc.)
Entities are data containers and should not depend on the presentation. Hence having a special entity (subclass) for one UI usecase (the form in your case) would violate the single responsibility principle and abstraction between model/data and view/presentation layer.
I'm developing (another) java web framework for personal use, and in addition to that I also want to develop somekind of persistence framework.
I have already developed and engine that in order to access the table, you must only extend a class and create your fields with the same type and name of those in the table. Ex:
private int id;
private String nome;
So you only need now to build the query and execute. The engine put the values on the right fields.
Recently I've had a quite good experience with Django, wich in order to update, create and filter the table you just need to call .save(), .create(field1=field, field2=213) and, .filter(filterfield=value).
I want to build this to, but I am having some trouble, because the extending class would actually have to write more, fact that I don't want to force. I have had the idea to the extending class write an enum implementing an Interface. So the super class get those fields, along with a private HashMap (the key is the enum) and keep the values, so the client just calls:
String nome = Usuarios.get(Usuarios.fields.name);
To retrieve the value.
Usuarios.update(new Pair(Usuarios.fields.name, "José Leal"), new Pair(Usuarios.fields.sobrenome, "Domingues"));
To update and so on.
Anyone have a better idea? I also use velocity framework, so I would like my field to be accessible by its getter.
ps: I know the existence of hibernate and etc.
I would suggest that you not force users to extend one of your own classes for their model objects. This locks them out of extending their own classes, and makes them more vulnerable to API changes you might make later.
Seeing as javax.persistence already defines annotations that can be used for mapping properties to a database, I'd suggest instead that you let the users make POJOs for their model objects with annotated properties. That way, along with the other mentioned benefits, you're following an already established standard and thereby lowering the barrier to entry for your users.