It would be nice to do, but i am not so sure if you can do this with criteria, perhaps with some sort of root transformer.
Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Mon, Aug 3, 2009 at 10:53 PM, Suiden <[email protected]> wrote: > > Thank you for your answer. I understand the DTO stuff is the right > thing to do, as opposed to reusing entities. > > On Aug 3, 10:08 pm, Tuna Toksoz <[email protected]> wrote: > > This is not a duplicated structure, you're not taking all props of cats, > > you're taking a subset. > Yes, this is true for that unique scenario. What about all the other > times when UI asks for a cat? It's the DTO which is sent to UI, so it > should have all the other properties on it too, right? That is, unless > I have another DTO for this type of request ( I didn't get whether > this is how I should do it or not, sorry) > > > This flattened structure is not really a problem, > > because you're wanting it, having oop-thing here doesn't make much sense, > > because you don't have anything except those, no other props at deeper > > level. > Does it depend on the use case, or Is there a golden rule saying DTOs > must never reflect the structure of the entities they represent? I > understand it's not worth the effort in this scenario but what about > sending all owners and their cats to UI? They should be rendered in a > tree-like manner: > * John Smith > * Kitty1 likes KittyKat > * Kitty2 likes Whiskas > * Joe Red > * Kitty3 likes KittyKat > ...and it makes sense for me to represent this data as a > List<PersonDto> defined as > * class PersonDto { List<CatDto> Cats & all other properties > previously defined } > * class CatDto { string PreferredFood & all other properties > previously defined } > > > It doesn't work because Cat perhaps waits for some other stuff, other > props > > etc. And Owner is not that thing. > > > > my 2 cents > > > > Tuna Toksöz > > Eternal sunshine of the open source mind. > > > > > http://devlicio.us/blogs/tuna_toksozhttp://tunatoksoz.comhttp://twitter.com/tehlike > > > > On Mon, Aug 3, 2009 at 9:50 PM, Suiden <[email protected]> wrote: > > > > > Hi guys, > > > > > I am developing a web application in C# using NHibernate and Flex for > > > UI. I recently ran into a performance issue which made me have second > > > thoughts regarding the way I used NH so far. > > > > > Say there are 2 entities having properties: > > > * class Person { Id, FirstName, LastName, P1.... Pn } > > > * class Cat { Id, Name, Owner, P1 ... Pn } // a cat is owned by a > > > person; owner is lazy loaded > > > > > Both entities are fully mapped to database (by which I mean classes > > > are mapped to tables and all their properties are mapped to columns), > > > so when I want to get a cat by Id I get this query: > > > * SELECT Id, Name, OwnerId, P1, ... Pn FROM Cat WHERE Id = x. > > > Let's say this is what users want to see most of the time. > > > > > But there's this scenario: how about showing the names of ALL cats and > > > their owners' names? Doesn't matter if there are thousand of cats, the > > > user wants to see them all. And yes, there are thousands of cats! > > > > > What I did so far (and now I think it's SO bad): > > > * var allCats = session.CreateCriteria<Cat>() > > > * .SetFetchMode("Owner", FetchMode.Join) > > > * .List<Cat>(); > > > > > This is a waste of performance: the query selects ALL columns from > > > both tables; I only needed 3 columns: > > > - 1 from Cat (Name) > > > - 2 from Person (FirstName, LastName) > > > That's 3 vs 2*(n + 3); for thousands of records I get a ton of useless > > > data. > > > > > So I figured I should use projections: > > > * var criteria = session.CreateCriteria<Cat>() > > > * .CreateAlias("Owner", "owner") > > > * .SetProjections( > > > * Projections.Property("Name").As("CatName"), > > > * Projections.Property("owner.FirstName").As > > > ("OwnerFirstName"), > > > * Projections.Property("owner.LastName").As("OwnerLastName")); > > > * var data = criteria.List<Cat>(); > > > > > This is where trouble begins: I can't get a list of cats! The best I > > > can get is a IList<CatDto>: > > > * criteria.SetResultTransformer(Transformers.AliasToBean<CatDto>()); > > > * var data = criteria.List<CatDto>(); > > > where CatDto is defined as: > > > * class CatDto { CatName, OwnerFirstName, OwnerLastName } > > > > > I must admit I gained a performance boost on the query side, but I > > > ended up with a DTO and I'm not sure if this is the right way to do > > > it. I'm not happy with: > > > > > 1) duplicated structure: CatDto should have all the properties of Cat > > > and of its associations; of these, only 1 is set in this scenario; but > > > maybe I should have a different DTO for each type of request? (e.g. > > > CatDtoForShowingNames) > > > > > 2) flattened hierarchy. cat.Owner.FirstName becomes > > > catDto.OwnerFirstName. What about cat.Owner.A.B.C....Z? Should DTOs > > > reflect the hierarchy of entities, such as catDto.OwnerDto.FirstName? > > > If so, could I get such an object from criteria? > > > > > 3) Why doesn't this work: > > > * criteria.SetResultTransformer(Transformers.AliasToBean<Cat>()); > > > * var cats = criteria.List<Cat>(); > > > It would just set the cat's name, create an owner for it using > > > reflection and set its first/last name...No need for DTOs whatsoever. > > > > > Please correct me if you think I am wrong, I'm just a beginner > > > anyway :) and please let me know what is the best way to handle this. > > > Thank you! > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
