Re: Design Question
Re: Design Question
- Subject: Re: Design Question
- From: James Cicenia <email@hidden>
- Date: Thu, 22 Jul 2004 17:19:28 -0500
Thank you Colin and Chuck -
My first conceptual problem is the difference between the class and the
object instantiation of it. I did incorrectly believe
that the classes would become bigger in memory.
Putting my logic in both my Business Class and in a manager class is
where I will head. When I did start refactoring
I felt that some of the logic did not belong in the Business Class and
that is where my "shadow" class or your manager
class got started... I thought at this point I better ask the pros. I
will continue the approach of moving my logic to both
the EOs and the Manager classes.
I knew that my original approach would be changed... but with a
deadline and some design on the fly and a new
IDE(Eclipse) and API WebObjects... it was just so easy to keep all the
code in my subcomponents. It is actually
very easy to keep oneself organized in this manner for debugging, etc.,
you always knew which component to
examine. It worked for me at the time. LOL, my personal self contained
version of extreme programming.
I look forward to my refactorization process now.. maybe I will use the
new eclipse 3.0 for a completely fresh start.
Thanks again.
On Jul 22, 2004, at 4:59 PM, Colin Clark wrote:
Hi James,
Generally speaking, query logic like this shouldn't be placed in your
components unless it's very specific to that page. In most cases,
reusable logic like this belongs either in a manager/controller layer
between your business objects and your components, or in the business
objects themselves. Otherwise, it's very easy to create unmanageable,
unrefactorable components loaded with logic that should be separated
from page-specific code.
As you say, your example of portfolios and projects is probably logic
that rightfully belongs within your Portfolio EO class. If you have a
to-many "projects" relationship, you'll find it very useful to have
access to custom sorting and filtering logic directly within the
Portfolio EO itself. For example, methods like
getProjectsSortedByName() or getAllUnderfundedProjects() are most
appropriate here.
I don't understand your concern about memory in terms of where you
should partition your logic. Just because a class contains a lot of
useful methods doesn't mean that each instance of that class will take
up more memory. Am I misunderstanding you?
Although there has been some philosophical debate about this, you can
basically think about your WOComponents as the controller layer in
your application. As a result, they should manage the connections
between presentation and business logic, containing contain
page-specific code and state management only.
In order to ensure that components remain simple and focused, I have
found it's extremely useful to create a set of manager classes that
act as a layer between your components and your EOs. This manager
layer is responsible for handling your own custom logic during
workflow operations such as creating and fetching EOs. Basically, it's
a place to put commonly-used logic that works with EOs but which
doesn't doesn't necessarily make sense within the EO itself. In
essence, the manager layer should act as a kind of high-level source
and sink for EOs, but shouldn't be misused in cases where the logic
rightfully belongs either in the EO itself or in some other object
more meaningful to the business process itself.
The tough part is deciding where particular pieces of code belong. My
only advice is to avoid only thinking about what components do and how
they look. Try to think as much as possible in terms of real-world
objects and the sorts of things you need to do with these objects.
Colin
On Thursday, July 22, 2004, at 04:56 PM, James Cicenia wrote:
Hello -
Due to the nature of a very intense deadline I created my first
WebObject
application and it rocks! Thanks again to all that have ever helped
me.
Now, as I go back through my code I start to think... is this really
the WO Way?
Here is my question... My pages/components are comprised of nested
sub components.
Originally, I had put all my query logic within these components. Now
I wonder, where is the
best place to put this logic? Should it be in my own EO class? This
would be ok, I think, for
some of the logic... for this portfolio give me a sorted list of
projects. Now this seems ok, because
I will only have one portfolio in memory per session at a time.
However, what about the project
classes? There will be many in memory at one time, so would no
necessarily want any query
logic there. Should there be some other "shadow" type class to do all
the queries? Should these
classes be instantiated at the Application level?
Just wondering what the pros do.
-James Cicenia
_______________________________________________
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.
---
Colin Clark
Dynamic Web and Database Development Lead,
Resource Centre for Academic Technology,
University of Toronto
_______________________________________________
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.