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 you never do this or always 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.

Is the pattern dropped or enforced by seam via helpful annotations?

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)

Please use your real name here - unless Monkey is indeed your first real name.

Christian Bauer wrote on Feb 14, 2008 07:25 PM:


Please use your real name here - unless Monkey is indeed your first real name.

Gladly

Its not my first name, but it is indeed the first name of my company.

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?

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 .

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

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

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.