[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
You could start with a generic DAO pattern that is just a thin wrapper around
an entity manager, something like the following:
| public interface GenericDao
| {
| public void save (T entity);
|
| public void delete (T entity);
|
| public void delete (Class clazz, Serializable
id) ;
|
| public T find (Class clazz, Serializable id) ;
|
| public List list (Class clazz) ;
|
| public T findByExample (T example);
|
| public List listByExample (T example);
| }
|
Then you'd still have the option to switch your persistence layer should the
need arise.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929477#3929477
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929477
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
DAOs are great for some applications. At my company a specific division felt that EJB3's less than stellar stored procedure supprt was enough of a reason to switch to ibatis. The group simply wrote up some slsbs that conformed to the existing interface and hotswapped their old ejb3 daos right out with minimal effort. Yet, if you do not ever forsee swapping out your persistence implementation, then you don't need to bother. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929413#3929413 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929413 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
IMO do what works for you. Design patterns are only guidelines. I prefer writers/authors that say "This is an interesting way to write a piece of code" rather than "This is how you should write your code" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929221#3929221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929221 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
Going through the EJB3 material around, you really don't see this scenario: anonymous wrote : | servlet --> Session Facade (SLSB) ---> DAO (SLSB) ---> Entity Bean | where SLSBs access entity POJOs via DAOs in the EJB3 environment. It is the defacto "way" in Spring since the framework is not agnostic to back-end providers (Hibernate, iBatis, JDBC etc) It seems "as mazz said", some people intermix the DAO and session bean concept; so they have a SLSB but call it a DAO. I agree with greening and would think that EJB3 does renders DAOs obsolete for us anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929187#3929187 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929187 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
Good points. Depends on what you call a "DAO".
| List resultList =
| em.createNamedQuery("userFavoritesEntity.findByUser")
| .setParameter("user", user)
| .getResultList();
|
Where that code lives could be called a DAO, no? And all other places that
need to run that query would then call that DAO method to perform that query.
But I see your point.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929138#3929138
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929138
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
More on this "EJB3 persistence renders DAOs obsolete":
We typically do not use DAOs in front of highly-complex RAM-based data
structures. So what makes databases so special that a DAO pattern emerged?
DAOs became popular in the JDBC days, when you had
queryMethod() {
let's say 100 lines of JDBC code to get a list joined with a set
}
Then came Hibernate, and people argued more weakly for DAOs. The argument I saw
said DAOs were good for abstracting different database types (mysql vs.
postgresql, etc).
Now with EJB3 we have a situation where the old pattern, DAO, has such weak
arguments that eliminating DAOs should be considered "reasonable", and that
using a DAO should require justification.
Here's our new line of code:
List resultList =
em.createNamedQuery("userFavoritesEntity.findByUser")
.setParameter("user", user)
.getResultList();
Should this code be in the class that calls the entity? Should this code be in
a static method on the entity? Those are questions for a later discussion.
The question I pose here is whether this code justifies a new class, a DAO.
In other words, does EJB3 persistence render DAOs obsolete?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929135#3929135
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929135
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
I am wondering whether EJB3 persistence renders DAOs obsolete. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929123#3929123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929123 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [EJB 3.0] - Re: DAOs as SLSBs - performance hit?
In my opinion, this should not be a problem - I doubt you would notice any non-trivial performance hit or even care. The I/O going to/from your backend data store (in addition to the data processing performed in the DB) will be the performance bottleneck and probably be orders of magnitude above that which your DAO will introduce. Worry about hitting the database and the I/O that introduces more than adding a DAO layer. A DAO layer above your entity beans is "a good thing". 'course, all of this is IMHO. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3929119#3929119 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3929119 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
