-
1. Re: Design patterns in Seam applications
christian.bauer Feb 14, 2008 10:18 AM (in response to hubaghdadi)Because we assume that developers are able to decide what they want based on facts and lists of advantages/disadvantages. This is called
making an informed decision
. If someone tells younever do this
oralways do that
, they are most of the time dead wrong.As far as DAOs are concerned, show me a single statement written by Seam developers that says
drop the DOA pattern
. I doubt you will find one. -
2. Re: Design patterns in Seam applications
hubaghdadi Feb 14, 2008 10:55 AM (in response to hubaghdadi)I'm not saying Seam developers are saying:
Drop the DAOs
.
All what I'm saying is Seam the framework make it easy to drop some design patterns from application, like DAO and service locater for example. -
3. Re: Design patterns in Seam applications
hubaghdadi Feb 14, 2008 10:59 AM (in response to hubaghdadi)Of course
Service Locater
can be dropped due the amazing DI/IoC... -
4. Re: Design patterns in Seam applications
degzhaus Feb 14, 2008 5:26 PM (in response to hubaghdadi)Is the pattern dropped or enforced by seam via helpful annotations?
-
5. Re: Design patterns in Seam applications
monkeyden Feb 14, 2008 7:14 PM (in response to hubaghdadi)
John Degner wrote on Feb 14, 2008 05:26 PM:
Is the pattern dropped or enforced by seam via helpful annotations?yeah, Seam 2.1 will include @OstracizePattern(
DAO
) -
6. Re: Design patterns in Seam applications
christian.bauer Feb 14, 2008 7:25 PM (in response to hubaghdadi)Please use your real name here - unless
Monkey
is indeed your first real name. -
7. Re: Design patterns in Seam applications
monkeyden Feb 14, 2008 7:37 PM (in response to hubaghdadi)
Christian Bauer wrote on Feb 14, 2008 07:25 PM:
Please use your real name here - unlessMonkey
is indeed your first real name.Gladly
Its not my first name, but it is indeed the first name of my company.
-
8. Re: Design patterns in Seam applications
degzhaus Feb 14, 2008 10:35 PM (in response to hubaghdadi)Nice, Kyle =D ... I actually meant this as a question: doeasn't the seam framework utilize the dao pattern in it's infrastructure in the EntityManager? In other words it's not dropping the pattern; but, instead, enforcing it?
-
9. Re: Design patterns in Seam applications
shahzeb Nov 18, 2008 4:16 AM (in response to hubaghdadi)The whole concept of DAO in seam is obnoxious . Yes we can use our own but one must wonder as what Gavin King and associated Monkeys (nothing personal Mr King I do have great admiration for your work including seam)were thinking when they decided to introduce XML .....slap me slap me please I must be dreaming ....... XML based DAOs . You got to be kidding . And that in the face of the promise of reducing the XML .
The fact that seam has this capability is infact confusing . I am happily using my own DAO's which are infact generic hibernate ones using java 5 generics .
-
10. Re: Design patterns in Seam applications
dro_k Nov 18, 2008 6:12 AM (in response to hubaghdadi)This is a really silly discussion. How can using Seam stop or enforce you to use a pattern? I think that should be at the sole discretion of the developer. If you see DI/IoC is getting in your way (injections have a performance overheard) then use the Service Locater (using Component.getInstance() or something else). If you see you are copy/pasting a lot of data access code, then make a component and call it a DAO. This applies to rest of the GoF design patterns too. Why does it have to be all or nothing? Seam's not a religion, just a tool to make life easier... hehe.
cheers,
Drew
-
11. Re: Design patterns in Seam applications
shahzeb Nov 18, 2008 6:45 AM (in response to hubaghdadi)It's not .... OMG
Joke aside , Yes I do agree with you but what got me by balls rather surprise was that idea of having DAO's in XML . Seam was better of not providing any thing in this regard than short circuiting living day lights out by giving the option of this bizare facility (talking about XML based DAOs) but yes I agree with you it does not stop from using your own but my point is just against XML based dao .
Also from experience we know that frameworks that give too many options in monolithic way (seam el etc ) rather than option to modularize like forexample spring die early . In spring you can choose what ever you want . I am by no means at all comparing spring with seam that would stupid very stupid but just trying to say how seam too could have bean plug an play. like use it with struts just for example . Instead of claiming to be a glue blah blah .
Also I must say that I am not against seam infact love it for it's core ideology that being a statefull frame work but it must not rely on other frameworks for example heavily relies on JSF and hibernate . Instead should focus on these layers rather than particular technologies. Yes may be give some benefit for using these suggested brands or technologies (what ever you want to call it ) but should not render itself useless against other poplular frame works e.g Struts and toplink ( yes there are people many of them who do not use hibernate)
Yes may be I do have lots of time to spare :D hahahaha
-
12. Re: Design patterns in Seam applications
accountclosed Nov 18, 2008 11:18 AM (in response to hubaghdadi)
when it encouraging us to drop such design patterns.You only mentioned one design pattern: DAO.
Actually one of the more interesting features the Seam offers (which may not strictly be considered as much of a pattern as it is a paradigm) is the pages.xml document/feature.
While this document looks like yet more
XML Hell
configuration, this document behaves similarly to the state information for the Card/Scripting paradigm that was used in multimedia authoring tools such as Apple's HyperCard where pages are defined, navigation is declarative, and restrictions are placed on page access.Build an application that allows the user to perform drag-and-drop with the pages.xml file and you'd essentially have an application looking suspiciously like HyperCard.
My point is, you may have lost the ability to create/use the DAO but you've gained a higher level view of what you are building which, I would think, is worth more since it cuts down considerably on development time.