you could use an interceptor (derrive from NHibernate.EmptyInterceptor) and on update you can tell NH which properties are dirty there you have the current and previous states (array of values of you entity's properties) you could then compare the properties yourself and if the Limit is null you can Not return that property's index as a dirty property if you use dynamic update (update only the dirty properties) and don't return the Limit property as a dirty property, it won't be nulled to the DB.
about the collection - if your invoice entity doesn't cascade to the Reactions, then it shouldn't be a problem That said, if you're providing services to another developers team (and not just developing the server side of your team's application) i do think that DTOs are better because you can then change your entities implementation without breaking your clients. If you're just developing your own project's server side services, then i would, just like you, try to avoid having a DTO per entity which is a big overhead. On Fri, Apr 9, 2010 at 12:32 PM, Gustavo Ringel <[email protected]>wrote: > In general it is better to avoid using real entities into the web services. > Normally you should use some kind of data contract like a DTO and the > clients are not exposed to your domain entities (even if you are developing > the clients) > You should map from your domain entities to DTO and the way back you act on > your domain upon the info on the DTO. > > Gustavo. > > On Fri, Apr 9, 2010 at 11:41 AM, F.B. ten Kate <[email protected]>wrote: > >> Greetings, >> >> I'm working on a project where we're returning NHibernate graphs from >> webservices and i've set up the systems to allow for users to specify >> which properties they do, and which they do not want returned. >> >> For example we have an Invoice class, which has one Debtor, a >> collection of Reactions and possibly a Limit. >> >> For some calls getting a debtor would not be needed and would only >> cause overhead, so users can specify this and due to lazy loading no >> call is ever made to the SQL server to retrieve this record. I then >> NULL the Debtor property so when serializing hits nothing is there to >> trigger a NHibernate call. >> >> The problem lies in the fact that when i try to save anything >> NHibernate thinks i should save my Invoice simply because the debtor >> property is now nulled. This isn't correct, now i can remedy this by >> setting the "not-null" to true in the mapping. I could probably also >> Evict the Debtor (or can i evict the invoice which would then evict >> the rest of the associated classes aswell???) so NHibernate does not >> realise it is dirty. >> >> The problem now lies in Reactions, this is also nullable in a way that >> the collection will not be loaded and my users don't generate any >> overhead. The problem now lies in when this collection get's updated. >> If the collection is set to NULL would this cause updates? I believe >> it shouldn't since no cascading has been set. (If i set cascading is >> there anyway to handle the situation discribed above?) >> >> Another problem would lie in the Limit property, not all invoices have >> a Limit. So i cannot set the property "not-null" to true, since it's >> simply not. However i also do not want the limit to be updated >> (Limit_ID to be set to NULL in the tbl_Invoice) if this property is >> nulled. >> >> What is the best way to handle a situation like this? I don't think >> i'm the first to attempt to use NHibernate with webservices but there >> aren't to many examples around (or i just suck at using google) >> >> Greetings, >> >> F.B. ten Kate >> >> -- >> 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]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- 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.
