Re: MVC pattern
From: Laird Nelson (lairdnelson_at_comcast.net)
Date: 04/26/04
- Next message: ak: "Re: how to make data frequency update and display on GUI"
- Previous message: harald ebert: "Two KeyBindings for one Action"
- In reply to: Roedy Green: "Re: MVC pattern"
- Next in thread: Roedy Green: "The virtues of Serialiased Qbjects"
- Reply: Roedy Green: "The virtues of Serialiased Qbjects"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 26 Apr 2004 11:04:42 -0400
Roedy Green wrote:
> If the persistence writeObject readObject is in the class it is
> persisting, you can in many cases get away with writing almost no
> code, just a bit of initialisation of transient fields.
Right, and then something else (an accessor) has to do the writing (e.g.
has to create an ObjectOutputStream, write to it, handle errors, etc.),
and then you have to be able to live with the file/wire format. This
works in many cases, and falls down in others.
> If you do the persistence in another class, you need a giant long list
> of calls to getters and setters to EVERYTHING that is persistable.
> Every time you add a new field this code has to be adjusted. It is
> hard to tell if you remembered everything.
Yes, that's correct. The computer cannot magically figure out what
fields you want, for example, to map to database columns.
> You have to create duplicate fields in your persister class and make
> sure the declarations stay in perfect sync.
I don't understand this.
Given the following dumb class:
public class Foo {
private String id;
private String bar;
private String baz;
public String getID() {
return this.id;
}
public void setID(final String id) {
this.id = id;
}
public String getBar() {
return this.bar;
}
public void setBar(final String bar) {
this.bar = bar;
}
}
...and its associated dumb "accessor":
public class FooStorage {
public static final void store(final Foo foo) {
if (foo != null) {
final String id = foo.getID();
if (id != null) {
somePersistenceSystem.write("foo." + id + ".bar",
foo.getBar());
}
}
}
}
...where are the duplicate fields in FooStorage? What needs to be kept
in sync?
> It is a heck of a lot of error-prone programmer work with very little
> payback. It for the computer, is only the overhead of each
> getter/setter.
I don't understand your last sentence, though I obviously get the gist
of your statement. I disagree. For many persistence systems, figuring
out what data goes where is at the core of why we write programs. We
have data in X and we need to get it into Y. Plug in any of the
following, respectively, for X and Y:
* an object of type Foo, an object of type Bar
* one company's idea of what a Person is, another company's idea of what
a Person is
* a tabular representation in a database, a domain model
* a filesystem, a database
* an object of type Foo, a database
* a table named Splatz with a schema of Garf, a filesystem
* a String, a structured object
* a fetid pile of stinking XML, another fetid pile of stinking XML
* a Java serialized object, yet another fetid pile of stinking XML
...and so on.
Cheers,
Laird
- Next message: ak: "Re: how to make data frequency update and display on GUI"
- Previous message: harald ebert: "Two KeyBindings for one Action"
- In reply to: Roedy Green: "Re: MVC pattern"
- Next in thread: Roedy Green: "The virtues of Serialiased Qbjects"
- Reply: Roedy Green: "The virtues of Serialiased Qbjects"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
