Hi masters


It's a conceptual approach.. Where I put the transaction statments of NHibernate (begin,commit,rollback), in the DAO layer or GUI layer?

I saw programmers using the statments in the DAO, others in GUI... Where is the best place to put this :cry: ..

I always used it in GUI layer...


Best Regards
Leandro
Brazil :wink:

I use a separate object which starts, commits and rollbacks transactions. This object is part of a class library which is part of my solution. My domain classes also reside in this class library, it's not part of my GUI. My actual project references this class library.
So make a new class library to put your domain objects and helper classes in. It depends on which level of separation you want, but I would choose the way I described above.

So, based in your explanation, by example:

-GUI
-DAO / TRANSACTIONS
-B.O. (domain)

or this approach:
-GUI
-TRANSACTIONS
-DAO
-B.O. (domain)


What approach do you use?


Best Regards...

I am more inclined to use a "Service Facade" design pattern to act as a boundary between the UI and domain objects. The service layer is a good point to provide security, logging and transaction control.

So I would suggest:
- UI
- Service Layer
- Domain

This approach enables you to encapsulate your workflow/orchestration business logic in another layer outside the UI, which is useful if you need to access your logic from more than one front end (such as multiple UIs or Web Services for example). The service layer can be reused between each front-end.

Personally, I subsribe to baggins' point of view. But I can see, and often agree, with points for placing the transactions in the DAO layer. But, besides these philosophical differences, each agrees that you should NOT place NH transactions in your UI layer. The UI layer really should have no knowledge of the perisistence layer.

imho, of course.

-devon