Re: db connect in session
Re: db connect in session
- Subject: Re: db connect in session
- From: Art Isbell <email@hidden>
- Date: Mon, 11 Aug 2003 10:19:16 -1000
On Saturday, August 9, 2003, at 07:41 AM, Jeff Martirano wrote:
in Session.java:
public EOEditingContext categoryEditingContext;
The session's default editing context is accessible from any component
by invoking session().defaultEditingContext(), so defining a Session
instance variable for this editing context is superfluous and results
in your app using a little more memory.
From n philosophical object-oriented programming perspective,
declaring instance variables public and accessing them directly
violates encapsulation. Public instance variables are akin to the bad
old global variables of the past. In general, it's better to make them
private or protected and access them via accessor methods.
WO changed its declaration of component keys in 5.2 from protected to
public so that WO can access these variables directly even when they
are defined in a Java package. There are some situations in which WO
must access variables directly rather then via accessor methods, but
that doesn't mean that we as programmers should declare our instance
variables public.
public Session() {
super();
categoryEditingContext = defaultEditingContext();
categoryFetchSpec = new EOFetchSpecification("Category", null,
null);
categoryList = new
NSMutableArray(categoryEditingContext.objectsWithFetchSpecification(cat
e
goryFetchSpec));
EOUtilities contains many convenience methods that can replace several
common statement sequences. The last three statements above could be
replaced by:
categoryList = new
NSMutableArray(EOUtilities.objectsForEntityNamed(defaultEditingContext()
, "Category");
categoryClassDescription =
EOClassDescription.classDescriptionForEntityName("Category");
category = new EOGenericRecord(categoryClassDescription);
and
category = EOUtilities.createAndInsertInstance(defaultEditingContext(),
"Category");
Then from WOBuilder I can use WORepitition to list the results, etc.
for different components without having to type all of the above info
into each component's java file.
Another possible approach would be to take advantage of inheritance.
You could define a WOComponent subclass (e.g., CategoryList) that
implements the common category list code. Then make each component
that uses a category list a CategoryList subclass. This avoids adding
this stuff to Session.
I generally view Application as a place to store state that might be
shared by more than one session (be careful if concurrent request
handling is enabled) and Session as a place to store state that might
be shared by more than one component. But I try to localize state in
the component where it will be used passing any state that the next
component might need directly to that component rather than using
Session as an intermediary.
Aloha,
Art
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.