IMHO there is no relation with anemic model and DTO usage, at least in my case.
For the AOM part, i already used this technique but performance is really hard to manage so never touch in this area :) Thx On Oct 10, 4:16 pm, Jason Meckley <[EMAIL PROTECTED]> wrote: > if you find yourself heavily using NH Projection directly to the GUI > then the domain model is anemic. I approach the GUI to domain problem > this way. > Gui > Presenters > Services > Repositories & PresenterMappers > > You do end up with alot of dtos and mappers but each one has exactly 1 > responsibility. More files, but each file is only a handful of lines. > In my current project I'm using an Adaptive Domain Model and passing > my entities (via an interface) directly to the gui instead of have > multiple mappers/dtos I have many interfaces. each with a handful of > either get (display data) or set (change state/persist) members. > > On Oct 10, 8:29 am, djinni <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
