Re: Using Design Patterns ???
Re: Using Design Patterns ???
- Subject: Re: Using Design Patterns ???
- From: Andrus Adamchik <email@hidden>
- Date: Mon, 24 Mar 2008 20:21:20 +0200
IMO all the answers about MVC are off target (although the links to WO
architecture are helpful by themselves). The fact that WO is MVC per
se has little to do with a decision to use DAO and such...
Since MVC was mentioned, let me delve into that. My assertion is that
calling WO (or most other modern UI frameworks, e.g. Swing) an "MVC"
is extremely confusing to the users. Classic MVC is not something you
or me want to deal with directly. It maybe MVC internally, but this is
not what a user sees. WO (or to a lesser extent, Swing) abstracts MVC
to a usable form by hiding most of the MVC parts interactions (via
bindings, WOComponent design, etc.). For instance consider that
WOComponent is not just a controller (action methods), but also a
model (get/set X), on top of another model - EOModel ... or you custom
non-EOF model if you wish. So squeezing this into an MVC paradigm is
counterproductive and gives a wrong impression.
On the other hand, WO is separated into distinct logical layers, but
those are NOT MVC. So look at the question about DAO from the POV of a
layered design. Here is an arbitrarily named classification of layers
in WO:
1. presentation template layer (.wod, .html)
2. presentation control layer (WOComponent.java)
3. persistence layer (EOF)
Traditional WO approach is to spread the business logic between (2)
and (3): static methods in the EO's, and action methods in the
components. Nothing wrong with that. Now if your business logic is
complex (or worse - the same API should differently in different
environments), you may want to stick another layer between 2 & 3...
Some DAO/Service layer or whatever you want to call it... An
abstraction of the UI-free logic. Once you start doing it, it becomes
addictive, and you start design around abstract services.
I'll defer to the people with more recent WO experience then mine on
*where* to put the DAO interfaces/classes. In a non-WO environment,
people use things like Spring. Static singletons can be a good start
(but not as flexible).
My advice, if you are new to that, start with traditional WO approach,
and when your if/else conditions become unmaintainable, move to the
abstract interface approach.
Cheers,
Andrus
---------------------------------------------
Andrus (aka Andrei) Adamchik
Apache Cayenne ORM: http://cayenne.apache.org/
Creator, VP Apache Software Foundation
On Mar 24, 2008, at 6:17 PM, Archibald Singleton wrote:
On 22 Mar 2008, at 19:17, Gustavo Pizano wrote:
Hello, well, while developing my application, I came to fork. To
Use or not TO use Design pattern??.... I mean should I implement
something like a DAO which will be in charge to communicate with
EO's, or should I make this directly from the .java of the
components.??
WebObjects uses the MVC design pattern. My understanding is that the
model part is your EOModel, the controllers are your
components .java files and the views are your .wo / .html (inline
bindings) files.
I'd recommend reading the legacy WO documentation (from WO 4.5.x) to
get a better understanding of the WebObjects from a architectural /
design pattern point of view. Even though the documentation is
outdated, it still provide valuable information that can't hardly be
found anywhere else.
http://developer.apple.com/referencelibrary/LegacyTechnologies/idxInternetWeb-date.html
In particular:
- WebObjects Developer's Guide
http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/DevGuideTOC.html
- EOF Developer's Guide
http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/EnterpriseObjects/DevGuide/GuideTOC.html
= tmk =
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden