Re: Design Question
Re: Design Question
- Subject: Re: Design Question
- From: Colin Clark <email@hidden>
- Date: Thu, 22 Jul 2004 17:59:02 -0400
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.