First of all thanks for all the answers. Let me clarify my point and cases in various cases.
1. For a constrained projection : Too much columns and i only want 3 or 4 of them then i use transformer or simple NH recognized simple DTOs 2. Lots of joins resulted with a unique view besides entity hierarchies : I already use HQL sometimes Criteria API however most of the time i need UI bound DTOs. These are pure value objects. 3. AOM : In the past I had a terrible AOM experience :) I know ORM is not a silver bullet but my solutions gets bigger and bigger with DTOs. Oguz On Oct 10, 2:44 pm, Jason Meckley <[EMAIL PROTECTED]> wrote: > 2 options: > 1. use an adaptive domain model approach have have interfaces specific > to the GUI, only exposing the necessary properities. > 2. use DTOs to explicitly express the intent of the GUI's data. This > is beneificial on a large project as each gui only has the data it > needs, no more, no less. > > On Oct 10, 4:39 am, "Gustavo Ringel" <[EMAIL PROTECTED]> wrote: > > > I agree.. in a simple model you can take in account eagerly loading (if it > > is very simple even use lazy=false) and you don't have to mess with DTO's. > > > When the domain is complex you are showing only parts of them to the user > > and it is a bit awkward to send the client a potentially complex graph... > > > You should always decide one or the other depending on the complexity of > > your domain and kind of app (win, web) and remember you can create always > > the DTO's from NH directly (using Transformers or select new or > > PositionalBean from uNHAddins) so you can end up with a fully NH created DTO > > instead of using Conversion/Translation classes... > > > Gustavo. > > > On Fri, Oct 10, 2008 at 10:31 AM, Sidar Ok <[EMAIL PROTECTED]> wrote: > > > Depends on how complex your domain is and what you are calling as DTOs . > > > Are the DTO s data holding classes directly from db, or the DTO s that you > > > are sending over the wire ? > > > > In most cases, NHibernate's mappings are good enough to handle complex > > > associations and relationships up to some extent. So there is no harm to > > > use > > > them directly, and surely is not an antipattern, and the easiest bet on > > > getting all the goodies of an ORM. > > > > If your domain model is more complex than that, then you will need > > > seperate > > > set of UI objects to bind to the screens anyway. > > > > Another option might be to generate those UI Bound objects or DTOs for the > > > wire from the model and domain respectively, but you need to be careful as > > > it may go out of hand. > > > > Hope this makes sense, if it doesn't please elaborate. > > > > Thanks. > > > > On Fri, Oct 10, 2008 at 9:46 AM, Oguz Bayram <[EMAIL PROTECTED]> wrote: > > > >> Hi, > > > >> While using NHibernate, excessive usage of DTOs bothers me so much. For > > >> each different presentation view we have to create DTOs and my solution > > >> blow > > >> up DTO class files. I am wondering this would be a antipattern or any > > >> workaround to handle this situation? > > > >> Thx > > > >> Oguz BAYRAM / Istanbul > > >> blog :http://www.oguzbayram.com > > > > -- > > > Sidar Ok > > >http://www.sidarok.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
