Athen
journeyman
Reged: 06/05/07
Posts: 79
Loc: San Francisco, CA
|
|
Hi John,
I liked your article a lot, but I've been struggling with this statement:
Quote:
...if you were modeling a row from a database ResultSet, without any preconceptions or framework constraints whatsoever, what would your design be like? Would it be similar to a JavaBean, or would it be significantly different?
I'm really used to the JavaBean paradigm of getters and setters, so I accepted your challenge to find a way for this. I'm a bit stumped where values do change, e.g. for a typical CRUD application. The only way I can think of doing this is to create a new object where the value is set through a constructor. Assuming the object has more than one field, the constructor would have to have three arguments:
1. The db object (a structure)
2. The name of the field to change
3. The new value
So where a JavaBean would change a name:
Code:
dbCustomer.setLastName("Smith");
I would need to create a new object.
Code:
dbCustomer = Customer(dbCustomer, "lastName", "Smith");
So I have two questions about this:
Q1: Isn't the expense of creating so many new objects (a new object created for every field value change) offsetting the gains of immutability in this case?
Q2: Is there a better way of applying immutability in this situation?
Posted for user by Athen
|
johanley
stranger
Reged: 07/29/08
Posts: 9
|
|
Charles,
Thanks for your question. (Sorry I took a bit long to reply.)
Immutable Model Objects seem to be fairly natural for web apps, but less natural for desktop apps.
Immutables are less natural for desktop apps,
because the user often needs to edit many items at once, and have all those edits applied en masse. If you need to apply edits all at once, then yes, using immutables is indeed a problem.
But for web apps, immutable Model Objects form a more natural default style.
Lets take an example. A web app deals with Paintings, say. A listing of Paintings is first displayed. On the server, a ResultSet is converted into a List of immutable Painting objects, and they are simply rendered in a JSP. No need for mutability there, right?
The immutable Painting objects would have a single constructor that takes all fields.
Code:
Painting(Long, String, Date, BigDecimal)
It would also have a number of getXXX methods, but no setXXX methods.
Next step: the user picks one of these Paintings. Its primary key identifies it. The user selects the item, the server fetches it from the db, converts it into a single Painting object, and presents it in a FORM. Again, no need for mutability there either. Just SELECT, convert into a Painting object, and display in the FORM.
Now the user enters changes into the form, and POSTs the changes. Heres the crux: the primary key is POSTed too, and identifies the original record to be changed. On the server, a new Painting is constructed, carrying the new, desired state for that Painting. It is used in an UPDATE statement, using the primary key to identify the record. So, there is not a single Painting object being changed. There are different Painting objects created for each request. They arent stored in session. They are created, used as needed for a given operation, and then discarded, all in a single request.
Quote:
Q1: Isnt the expense of creating so many new objects (a new object created for every field value change) offsetting the gains of immutability in this case?
For the case of a web app, the cost of creating a new Model Object for each request is usually trivial. Remember the size of stack traces in Tomcat, for example? There is a heck of a lot happening already on your server. Creation of a Model Object is not something I would generally spend time worrying about, except in the most extreme cases.
Quote:
Q2: Is there a better way of applying immutability in this situation?
I hope the above response clarifies this.
To get a better understanding, you could down load the free example application that comes with the web4j tool that I built. There is a lot of example code there. Its a web app whose Model Objects are all immutable. (Look for the Resto feature, for example.)
Download:
http://www.web4j.com/Download.jsp
Regards,
John
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
