ORM and DAO are orthogonal concepts. One has to do with how objects are mapped to database tables, the other is a design pattern for writing objects that access data. You don’t choose ‘between’ them. You can have ORM and DAO is the same application, just as you don’t need ORM to use the DAO pattern.
That said, while you never really need anything, you should use DAOs. The pattern lends itself to modularized code. You keep all your persistence logic in one place (separation of concerns, fight leaky abstractions). You allow yourself to test data access separately from the rest of the application. And you allow yourself to test the rest of the application isolated from data access (i.e. you can mock your DAOs).
Plus, following the DAO pattern is easy, even if implementing data access can be difficult. So it costs you very little (or nothing) and you gain a lot.
EDIT —
With respect to your example, your login method should be in some sort of AuthenticationService. You can handle exceptions there (in the login method). If you used Spring, it could manage a bunch of things for you: (1) transactions, (2) dependency injection. You would not need to write your own transactions or dao factories, you could just define transaction boundaries around your service methods, and define your DAO implementations as beans and then wire them into your service.
EDIT2
The main reason to use the pattern is to separate concerns. That means that all your persistence code is in one place. A side effect of this is, test-ability and maintainability, and the fact that this makes it easier to switch implementations later. If you are building Hibernate based DAOs, you can absolutely manipulate the session in the DAO, that is what you are supposed to do. The anti pattern is when persistence related code happens outside of the persistence layer (law of leaky abstractions).
Transactions are a bit trickier. At first glance, transactions might seem to be a concern of persistence, and they are. But they are not only a concern of persistence. Transactions are also a concern of your services, in that your service methods should define a ‘unit of work’, which means, everything that happens in a service method should be atomic. If you use hibernate transactions, then you are going to have to write hibernate transaction code outside of your DAOs, to define transaction boundaries around services that use many DAO methods.
But note that the transactions can be independent of your implementation — you need transactions whether or not you use hibernate. Also note that you don’t need to use the hibernate transaction machinery — you can use container based transactions, JTA transactions, etc.
No doubt that if you don’t use Spring or something similar, transactions are going to be a pain. I highly recommend using Spring to manage your transactions, or the EJB spec where I believe you can define transactions around your services with annotations.
Check out the following links, for container based transactions.
Container-Managed Transactions
What I am gathering from this is that you can easily define the transactions outside the DAOs at the service level, and you don’t need to write any transaction code.
Another (less elegant) alternative is to put all atomic units of work within DAOs. You could have CRUD DAOs for the simple operations, and then more complicated DAOs that do more than one CRUD operations. This way, your programmatic transactions stay in the DAO, and your services would call the more complicated DAOs, and wouldn’t have to worry about the transactions.
The following link is a good example of how the DAO pattern can help you simplify code
AO vs ORM(hibernate) pattern
(thanx @daff)
Notice how the definition of the interface makes it so that you business logic only cares about the behavior of the UserDao. It doesn’t care about the implementation. You could write a DAO using hibernate, or just JDBC. So you can change your data access implementation without affecting the rest of your program.